[Mesa-dev] [PATCH V3] glapi: add GL_OES_geometry_shader extension

Ian Romanick idr at freedesktop.org
Wed Jan 13 15:24:44 PST 2016


On 01/13/2016 12:55 AM, Tapani Pälli wrote:
> On 01/13/2016 10:29 AM, Lofstedt, Marta wrote:
>>
>>> -----Original Message-----
>>> From: ibmirkin at gmail.com [mailto:ibmirkin at gmail.com] On Behalf Of Ilia
>>> Mirkin
>>> Sent: Tuesday, January 12, 2016 7:09 PM
>>> To: Marta Lofstedt
>>> Cc: mesa-dev at lists.freedesktop.org; Romanick, Ian D; Lofstedt, Marta
>>> Subject: Re: [PATCH V3] glapi: add GL_OES_geometry_shader extension
>>>
>>> On Tue, Jan 12, 2016 at 9:13 AM, Marta Lofstedt
>>> <marta.lofstedt at linux.intel.com> wrote:
>>>> From: Marta Lofstedt <marta.lofstedt at intel.com>
>>>>
>>>> Add xml definitions for the GL_OES_geometry_shader extension and
>>>> expose the extension for OpenGL ES 3.1.
>>>>
>>>> V3: Added dependency to OES_shader_io_blocks and updated to correct
>>>> Khronos extension number.
>>> May I ask why you did this? OES_shader_io_blocks is a purely shader
>>> compiler/linker feature, I expect it will be enabled whenever GLES
>>> 3.1 is
>>> enabled, no? Why would it be tied to geometry shaders? Sure, geometry
>>> shaders require it to work, but just because you have
>>> OES_shader_io_blocks
>>> doesn't necessarily mean you also have geometry shaders...
>>>
>> My intension was to address the co-dependency between
>> oes_geometry_shader and oes_shader_io_block.
>> But as always, you are right Ilia. The dependency issue need to be
>> fixed in the driver.
>>
>> So, please disregard this V3, I will push the V2 with the changes
>> suggested by Ilia in the comments.
>>
>> FYI here are quotes from the oes_geometry_shader specification:
>> " OES_shader_io_blocks or EXT_shader_io_blocks is required."
> 
> IMO according to this it looks OES_shader_io_blocks is a valid
> requirement as that functionality is not part of OpenGL ES 3.1.

True.  Any driver that enables OES_geometry_shader but does not also
enable OES_shader_io_blocks has a bug.  OES_shader_io_blocks is
necessary but not sufficient.




More information about the mesa-dev mailing list