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



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