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

Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction)



On Tue, Aug 30, 2011 at 2:32 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
>
> Thanks. If the spec is too unclear for you to support attaching float
> textures to FBOs, then maybe we should explicitly disallow that in WebGL,
> for portability's sake.

I don't think we need to -- various combinations of attachments on
FBOs aren't guaranteed to work; so the FBO completeness check should
fail on platforms where you can't render to a float texture FBO.

    - Vlad


> On 30/08/11 02:23 PM, Ribble, Maurice wrote:
>>
>> In our current drivers we support GL_OES_texture_float,
>> GL_OES_texture_half_float, and GL_OES_texture_half_float_linear. ÂIn order
>> to render to an FP buffer there is a lot of spec language that needs to be
>> added and these extensions don't have anything about that so I don't think
>> it is legal to bind these formats to an FBO. ÂYou would need to have
>> additional extensions defining clamp and a bunch of other things.
>>
>> -Maurice
>>
>> -----Original Message-----
>> From: Benoit Jacob [mailto:bjacob@mozilla.com]
>> Sent: Tuesday, August 30, 2011 1:53 PM
>> To: Ribble, Maurice
>> Cc: Christian Junker; public_webgl@khronos.org
>> Subject: Re: [Public WebGL] readPixles() can't access float values
>> (OES_texture_float interaction)
>>
>> What do you mean? I was not aware of the distinction between "texturing"
>> and "rendering" formats. Isn't it allowed to use a float texture as the
>> color attachment of a framebuffer? Why disable readPixels on such
>> framebuffers then?
>>
>> Regardless, are you saying that this is unsupported on Qualcomm
>> chips/drivers?
>>
>> Cheers,
>> Benoit
>>
>> On 30/08/11 01:48 PM, Ribble, Maurice wrote:
>>>
>>> They are only texturing and not for rendering, therefore readpixels does
>>> not make sense.
>>>
>>> -Maurice
>>>
>>> -----Original Message-----
>>> From: owner-public_webgl@khronos.org
>>> [mailto:owner-public_webgl@khronos.org] On Behalf Of Benoit Jacob
>>> Sent: Tuesday, August 30, 2011 1:26 PM
>>> To: Christian Junker
>>> Cc: public_webgl@khronos.org
>>> Subject: Re: [Public WebGL] readPixles() can't access float values
>>> (OES_texture_float interaction)
>>>
>>>
>>> As far as I can see, this question boils down to whether or not all
>>> OpenGL[ES] implementations which support float textures also support
>>> readPixels on them.
>>>
>>> If they do support that, then I don't see why we shouldn't support that
>>> too.
>>>
>>> If some of them don't support that, then there's no way that we'll be
>>> able to support that on top of them.
>>>
>>> Does anyone know how widely this is supported?
>>>
>>> Cheers,
>>> Benoit
>>>
>>>
>>>
>>> On 26/08/11 07:20 AM, Christian Junker wrote:
>>>>
>>>> Hi,
>>>>
>>>> Although floating point textures are supported through the
>>>> "OES_texture_float" extension, it is currently not possible to read
>>>> back the pixels from the framebuffer.
>>>> Using readPixels() does only work fÃr UNSIGNED_BYTE (as described in the
>>>> spec).
>>>> The specification of the extension
>>>>
>>>> (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt)
>>>> doesn't mention interaction with readPixels() at all.
>>>>
>>>> My question now is, is this an oversight or desired behavior? (or did
>>>> I simply overlook something?)
>>>>
>>>> I think allowing readPixels() to play together with floating point
>>>> textures would be a highly desireable feature, esp. for
>>>> diagnosing/debugging and gpgpu.
>>>>
>>>>
>>>> Short example:
>>>>
>>>> var pixels = new Float32Array(framebuffer.width * framebuffer.height *
>>>> 4);
>>>> gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA,
>>>> gl.FLOAT, pixels);
>>>>
>>>> results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406"
>>>>
>>>>
>>>> Rest Regards
>>>> Christian
>>>>
>>>> -----------------------------------------------------------
>>>> 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
>>> -----------------------------------------------------------
>>>
>>
>
>
> -----------------------------------------------------------
> 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
-----------------------------------------------------------