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. 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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev