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

Re: [Public WebGL] WEBGL_depth_texture unspecified case: sampling from an uninitialized depth texture



IIRC ANGLE supports depth-texture-only FBOs so no dummy colorbuffers
should be required on ANGLE.
But, yes you'd have to create an FBO to attach it to for clearing purposes.
On other implementations you should be able to upload initial texture data
to depth textures (or use the handy-dandy ARB_clear_texture api designed
for such purposes!)

WRT to renderbuffers, I'd agree with Olli. What is to stop someone from
creating a renderbuffer, attaching it to an FBO and then doing ReadPixels
from it?  Even if you tracked that it had been rendered to first, there is
no guarantee that all the pixels have been touched if you donĀ¹t clear it
first.  The same should would hold for depth textures. If you treat it as
incomplete until it's been rendered to, how do you know that every texel
has been initialized?

-Daniel


On 2013-09-26 3:48 PM, "Benoit Jacob" <bjacob@mozilla.com> wrote:

>On 13-09-26 03:26 PM, Daniel Koch wrote:
>> I think Chrome either initializes or clears all textures before use.
>> While you can't provide initial data for an ANGLE_depth_texture texture
>> you still should be able to attach it to an FBO and clear it.
>
>Yes, but the novelty here, compared to the case of renderbuffers, is
>that we would have to construct a whole new framebuffer (maybe with a
>color attachment created just for that) and check its completeness. This
>is different from the renderbuffer situation because with renderbuffers,
>as they can only be readPixels() from and not sampled from, the only
>framebuffer that we had to check for completeness was the one we were
>_actually_ going to render to, so that 1) we didn't need to create a
>dummy color buffer and 2) no matter how unpredictable framebuffer
>completeness is (on actual drivers), we had a guarantee that we'd have
>initialized renderbuffers before we'd allow reading pixels.
>
>So here, rather than talking the slow and fragile route of creating a
>dummy framebuffer just to clear the depth texture, I would rather treat
>that case as an incomplete texture so that we would take the existing
>code path that samples from a dummy 1x1 rgba(0,0,0,0) texture.
>
>In fact, spec-wise, that doesn't make any difference --- but I think
>that given that the case of incomplete textures is already specified,
>the simplest way to handle the present case is to clarify that it is an
>incomplete texture.
>
>Benoit
>
>
>
>>
>> (Ken: feel free to correct me based on actual implementation details.
>>I'm
>> basing this from memory of some discussions I had with Greg.)
>>
>> -Daniel
>>
>>
>>
>> On 2013-09-26 3:05 PM, "Benoit Jacob" <bjacob@mozilla.com> wrote:
>>
>>> Hi,
>>>
>>> WEBGL_depth_texture introduces a basic possibility that does not exist
>>> in the core WebGL spec: the possibility of an uninitialized texture.
>>>
>>> While uninitialized renderbuffers are only an implementation detail
>>>that
>>> doesn't have any existence at the level of the WebGL spec,
>>>uninitialized
>>> textures are different because they can be sampled from.
>>>
>>> The question is what should the spec mandate implementations to do when
>>> executing code like this:
>>>
>>>   CreateAndTexImage2DSomeUninitializedDepthTexture();
>>>   SetUpRenderingStateSamplingFromThatTexture();
>>>   Draw();
>>>
>>>
>>> It's not technically an INVALID_FRAMEBUFFER_OPERATION since the
>>> uninitialized texture here is one we are sampling from, not one we are
>>> rendering to. So should that be an INVALID_OPERATION?
>>>
>>> Note: I'm running into this while implementing support for
>>> WEBGL_depth_texture on clients supporting only ANGLE_depth_texture. I
>>> understand that Chrome already supports that. I would like to know what
>>> is Chrome's current behavior there.
>>>
>>> Thanks,
>>> Benoit
>>>
>>> -----------------------------------------------------------
>>> 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
-----------------------------------------------------------