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

[Dave Airlie]

On 3 December 2014 at 08:46, Dave Airlie <airlied at gmail.com> wrote:
> 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.

I just put up the piglit results from Ironlake

http://people.freedesktop.org/~airlied/piglit/ilk/enabled.html

being the interesting page.

Dave.