On 3 December 2014 at 08:46, Dave Airlie <airl...@gmail.com> wrote: > On 3 December 2014 at 07:32, Ian Romanick <i...@freedesktop.org> wrote: >> On 12/02/2014 12:51 PM, Eric Anholt wrote: >>> Ian Romanick <i...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev