On Tue, May 20, 2014 at 7:38 AM, Rogovin, Kevin <kevin.rogo...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev