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

[Dave Airlie]

On 3 December 2014 at 07:32, Ian Romanick <idr at freedesktop.org> wrote:
> 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.

>From a piglit run on ILK,

AMD_shader_trinary_minmax
ARB_draw_elements_base_vertex
ARB_explicit_attrib_location
ARB_explicit_uniform_location
ARB_shader_bit_encoding
ARB_texture_query_levels
ARB_texture_query_lod
ARB_texture_rg
ARB_texture_rgb10_a2ui
EXT_shader_integer_mix
EXT_texture_integer
ARB_separate_shader_objects

all had new tests enabled with my patch.

Eric, gl_VertexID is one thing glamor needs isn't it?

Dave.