[Mesa-dev] [PATCH] [RFC] MESA_shading_language_130: is this it?

[Ian Romanick]

On 12/02/2014 12:51 PM, Eric Anholt wrote:
> Ian Romanick <idr at freedesktop.org> writes:
> 
>> On 11/26/2014 06:09 PM, Dave Airlie wrote:
>>> Glamor is 4x faster on my ILK using glsl 130 at core text using
>>> x11perf -ftext.
>>>
>>> Ian started writing a spec for this extension a while back, which seems like
>>> most of the work, this patch seems to do enough, to advertise GLSL 1.30.
>>
>> Yeah... I started writing the extension when Chris Forbes was working on
>> adding GLSL 1.30 for Ironlake.  I seem to recall that gl_ClipDistance
>> still does not work for ILK, and difficulties with that caused Chris to
>> abandon the project.  This was over a year ago, so the details are a bit
>> fuzzy.
>>
>> The common Mesa parts look good, though.  If we want to pursue this, I
>> can finish up the extension spec and get it published.
> 
> I'd definitely be interested -- integers are really useful for 2D
> rendering (as evidenced by Dave's numbers), and I can do them in VC4.
> What I see in a glance through 1.30 that I don't have in my 2.1
> implementation is:
> 
> - Size queries (but I can fake it with uniforms)
> - Texture arrays (can't fake that without some real craziness).
> - Texture offsets (could fake with uniforms and some math?)
> - gl_VertexID (could fake with a cached VBO of integers I think.
> 
> I'd be interested in whether the MESA_1.30 spec would require support
> for extensions that expose those things, or if I could expose it without
> doing all of that.

I think it would be easy to have an interaction with
GL_ARB_texture_array at least.  I think the easiest thing is:

Interactions with EXT_texture_array and OpenGL 3.0

    If EXT_texture_array or OpenGL 3.0 are not supported, shaders using
    sampler1DArray, sampler2DArray, isampler1DArray, isampler2DArray,
    usampler1DArray, usampler2DArray, sampler1DArrayShadow, or
    sampler2DArrayShadow types or built-in functions related to those
    types will compile and link.  However, since textures for those
    targets cannot be created, these shaders will fail draw-time
    validation checks.

Would that work?  I think we'd need a nearly identical interaction for
EXT_texture_integer.  There may be other similar cases.

For the other things... it seems better to leave them in as-is.  GLSL
1.30 is largely a roll-up of existing extensions.  The idea behind
MESA_shading_language_130 was to provide enough API infrastructure to
make GLSL 1.30 shaders work.  If we subtract things from GLSL 1.30 due
to missing extensions, it seems like the value of the Mesa extension is
diminished.

If we're really just trying to enable glamor, maybe it would be better
to have an extension that just enables "true" integer support in GLSL
and the API.  Then we could enable it on Gen4 too.

Is there other hardware that would benefit from
MESA_shading_language_130?  A hypothetical MESA_shading_language_integer
extension?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141202/bed6ed18/attachment.sig>