[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] framebuffer-object-attachment test is not passable




On 03/12/11 12:59 PM, Benoit Jacob wrote:

On 03/12/11 11:46 AM, Mo, Zhenyao wrote:
((allowedStatuses & ALLOW_COMPLETE) && (status ==
gl.FRAMEBUFFER_UNSUPPORTED))

should be

((allowedStatuses & ALLOW_UNSUPPORTED) && (status ==
gl.FRAMEBUFFER_UNSUPPORTED))

two instances.

Otherwise looks good.

Thanks. I've checked this in, as r16237.

There seem to be only 2 kinds of errors in Chrome 17, similar to the
issues I'm fixing in Firefox at the moment:

1. It generates FRAMEBUFFER_UNSUPPORTED instead of
FRAMEBUFFER_INCOMPLETE_ATTACHMENT on incomplete attachments, e.g. when
an attachment has size 0 or is attached to a mismatched attachment point
(e.g. depth buffer on stencil attachment point)

2. It generates NO_ERROR instead of INVALID_FRAMEBUFFER_OPERATION when
doing a readPixels with width=height=0 on a framebuffer that is
incomplete because its attachments have 0 dimensions.

I forgot to mention a significant change in the version that I checked in, compared to what I attached to this email. After I fixed the typo you pointed out, I started getting failures as my NVIDIA 275 driver on linux x86-64 generates FRAMEBUFFER_UNSUPPORTED in the "Attach stencil using STENCIL_ATTACHMENT" case, where we have a color buffer and a stencil buffer but no depth buffer.


I am not familiar enough with these things to decide whether this is a driver bug, or a legitimate implementation-dependent case.

So, in doubt, I did this:

// some cases involving stencil seem to be implementation-dependent
var allowedStatusForImplDependentCase = allowedStatusForGoodCase | ALLOW_UNSUPPORTED;


[...]

debug("Attach stencil using STENCIL_ATTACHMENT");
testAttachment(gl.STENCIL_ATTACHMENT, stencilBuffer, allowedStatusForImplDependentCase);



Feel free to change this, either by just removing this hack (i.e. we decide that it's a driver bug and we decide to go ahead and expose it) or by using allowedStatusForImplDependentCase in more cases, perhaps even for all non-conflicted stencil cases?


Cheers,
Benoit


Cheers, Benoit



On Sat, Dec 3, 2011 at 1:43 AM, Benoit Jacob <bjacob@mozilla.com <mailto:bjacob@mozilla.com>> wrote:

Here is a work-in-progress patch for the
framebuffer-object-attachment test. Does this look OK?

Benoit


On 03/12/11 02:12 AM, Benoit Jacob wrote:


Hi,

If I'm not mistaken, the second testAttachment call in
framebuffer-object-attachment is not passable. It is:

debug("Attach depth using STENCIL_ATTACHMENT");
testAttachment(gl.STENCIL___ATTACHMENT, depthBuffer, true);

This is attaching a renderbuffer with DEPTH format to the STENCIL
attachment point of a newly created framebuffer, and requiring the
resulting framebuffer status to be FRAMEBUFFER_UNSUPPORTED.

If I understand it correctly, the OpenGL ES 2.0.25 spec requires the
status to be FRAMEBUFFER_INCOMPLETE___ATTACHMENT in this case.
Indeed, on
page 118 it says that FRAMEBUFFER_INCOMPLETE___ATTACHMENT is
returned if
some framebuffer attachment point is not "Framebuffer Attachment
Complete" while FRAMEBUFFER_UNSUPPORTED is returned in
implementation-dependent cases.

The present case (DEPTH format buffer attached to STENCIL attachment
point) is not an implementation-dependent case, and violates the
"Framebuffer Attachment Complete" rules given on page 117: "If
attachment is STENCIL_ATTACHMENT, then image must have a
stencil-renderable internal format."

Thus, FRAMEBUFFER_INCOMPLETE___ATTACHMENT must be returned in
this case.

To fix this, I propose that instead of the current isConflicted
parameter, the testAttachment takes a bit-field, each bit allowing a
different error status.

Cheers,
Benoit

------------------------------__-----------------------------
You are currently subscribed to public_webgl@khronos.org
<mailto:public_webgl@khronos.org>.
To unsubscribe, send an email to majordomo@khronos.org
<mailto:majordomo@khronos.org> with
the following command in the body of your email:
unsubscribe public_webgl
------------------------------__-----------------------------





-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------



-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------