[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

On 13-09-26 04:46 PM, Daniel Koch wrote:
> IIRC ANGLE supports depth-texture-only FBOs so no dummy colorbuffers
> should be required on ANGLE.

Ah, that is interesting.

> 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?
We always clear uninitialized renderbuffers entirely with glClear before
drawing anything to them. So we can easily do the same for textures. I
was only saying, that that is not enough by itself because we also have
to take care of something that wasn't an issue before: sampling from a
depth texture that has never been attached to a FBO and rendered to. I
was saying that we should do BOTH things, not that either would be
sufficient. But the new information, that ANGLE unconditionally supports
depth-only FBOs, is interesting, and may make me change my mind!


> -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