[Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.

[Marek Olšák]

On Tue, May 20, 2014 at 7:38 AM, Rogovin, Kevin <kevin.rogovin at intel.com> wrote:
>
>>> For OpenGL ES, I propose a simpler solution:
>>> - don't touch ARB_texture_float at all
>>> - add OES_texture_float to gl_extensions
>>> - add OES_texture_float_linear to gl_extensions
>>> - define OES_texture_half_float as o(OES_texture_float)
>>> - define OES_texture_half_float_linear as o(OES_texture_float_linear)
>>>
>>> Then, drivers can enable the extensions as they see fit.
>
>>That sounds like a happy medium.  It seems like we could use
>>ARB_texture_float as the enable for OES_texture_float, but I'm not
>>crying over one extra flag.
>
> I think it is actually the most unhappy medium. The patch as-is enable floating point
> textures in GLES2 on hardware targets without affecting any DRI drivers (or the Gallium state tracker).
> That was the original purpose of the patch. On one side: having 4 separate booleans then
> gives complete resolution to the situation for floating point textures. Having just -2- means that
> some resolution is provided but it is not complete and will then need to be revisited and leave
> whoever made or pushed the patch embarrassed about not dotting the i's and crossing the t's.
> Additionally, adding 2 or 4 and leaving ARB_texture_float, we are still left with the situation
> that the booleans are not orthogonal. Also, what does ARB_texture_float support
> then mean? What contract is it satisfying that mesa/main can rely upon?
>
> Going further what happens when/if we want to add support for GL_ARB_ES2_compatibility
> and also expose OES extensions (as NVIDIA does)? [I admit exposing OES extension in
> a non-ES context sounds gross, but the whole point of ES2_compatibility is to make ports
> from GLES to GL almost a no-op, so the OES extensions should come too].
>
>>It will mean that a bunch of extension checks in the code will need to
>>be expanded.
>>
>>We'll probably also want a negative test that verifies an error is
>>generated for glTexParameteri(..., GL_LINEAR_MIPMAP_LINEAR) when
>>OES_texture_float_linear (or OES_texture_half_float_linear) is not
>>supported.
>
> This is the other reason why I do not want to go down the multiple booleans initially
> as then the patch touches much more code; the all or nothing approach avoided
> all sorts of additional ickiness.
>
> Lets put the patch as-is (because from the point of view of mesa/main it looks correct)
> and then a subsequent patch, after some discussion, to support situations like the
> r300 partial floating point texture support.

Sounds good to me.

Marek