Christoph, This looks good. Thanks for bringing this back to life.
Keith On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote: > On 12/14/2010 12:36 PM, Keith Whitwell wrote: > > On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote: > >> I want to warm this up again adding nvc0 and > >> GL_ARB_separate_shader_objects to the picture. > >> > >> The latter extends GL_EXT_separate_shader_objects to support user > >> defined varyings and guarantees well defined behaviour only if > >> - varyings are declared inside the gl_PerVertex/gl_PerFragment block the > >> blocks match exactly in name, type, qualification, and (most > >> significantly) declaration order. > >> - varyings are assigned matching location qualifiers: > >> like: layout(location = 3) in vec4 normal > >> "The number of input locations available to a shader is limited." > >> > >> So, I propose to (loosely) identify GENERIC semantic indices with these > >> location qualifiers and let the pipe driver set a limit on the allowed > >> maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least > >> support 219 of them - nvc0 offsers 0x200 bytes for generic inputs/outputs). > > > > This sounds fine actually. We kicked this around before & I was > > basically ok with the last iteration of the proposal, but this seems ok > > too. > > > > As far as I can tell from a gallium perspective you're really just > > proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would > > be clearer), which the state tracker thereafter has to respect? > > > > That would be fine with me. > First attempt at a patch introducing such a cap attached. > > > > >> My motivation is mostly that the hardware routing table for shader > >> varyings that was present on nv50 has been removed with nvc0 (Fermi). > >> And I'm glad, because filling 4 routing tables (since we have 5 shader > >> types now) is somewhat annoying. And so applying relocations to shaders > >> - it can be done, it's probably not too time consuming, but it's just > >> plain *unnecessary* (and thus stupid) for OpenGL. > >> > >> Now about d3d9 ... > >> 1. don't care, I don't see a d3d9 state tracker > >> 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx > >> says "n is an optional integer between 0 and the number of resources > >> supported" - what "supported" means here isn't clear to me, but, I > >> didn't find any example where someone used something OpenGL doesn't have > >> (like COLOR2). > >> 3. > >> http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics > >> says "Input semantics are similar to the values in the D3DDECLUSAGE." > >> and > >> DECLUSAGE sounds like you're limited to sane values. > > > > I think you're on the right track with (1)... It's fairly pointless > > trying to discuss code here which isn't public & I don't think people > > need to be worrying about what may or may not be important for code they > > can't see. > > > > I know this idea previously got tied up with speculation about what a > > DX9 state tracker might or might not require, but in retrospect I wish > > I'd been able to steer conversation away from that. > > > > The work on closed components may drive a lot of the feature development > > and new interfaces, but there's usually enough flexibility that this > > sort of cleanup isn't a big deal. > > > > > > Keith > > > >> Not sure if anyone wants to think about this issue at this time (since > >> implementation of ARB_separate_shader_objects is probably far in the GL4 > >> future), but I'd be happy about any comments. > >> > >> Regards, > >> Christoph > >> > >> On 04/13/2010 12:55 PM, Luca Barbieri wrote: > >>> This patch series is intended to resolve the issue of semantic-based > >>> shader linkage in Gallium. > >>> It can also be found in the RFC-gallium-semantics branch. > >>> > >>> It does not change the current Gallium design, but rather formalizes some > >>> limitations to it, and provides infrastructure to implement this model > >>> more easily in drivers, along with a full nv30/nv40 implementation. > >>> > >>> These limitations are added to allow an efficient implementation for both > >>> hardware lacking special support and hardware having support but also > >>> special constraints. > >>> > >>> Note that this does NOT resolve all issues, and there are quite a bit > >>> left to future refinement. > >>> > >>> In particular, the following issues are still open: > >>> 1. COLOR clamping (and floating point framebuffers) > >>> 2. A linkage table CSO allowing to specify non-identity linkage > >>> 3. BCOLOR/FACE-related issues > >>> 4. Adding a cap to inform the state tracker that more than 219 generic > >>> indices are provided > >>> > >>> This topic was already very extensively discussed. > >>> See > >>> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html > >>> for some early inconclusive discussion around an early implementation > >>> that modified the GLSL linker (which is NOT being proposed here) > >>> See > >>> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12016.html > >>> for some more discussion that seemed to mostly reach a consensus over > >>> the approach proposed here. > >>> See in particular > >>> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12041.html > >>> . > >>> > >>> That said, I'm going to try to repeat all information here, partially by > >>> copy&pasting from earlier messages. > >>> This message should probably be adapted into gallium/docs if/when this is > >>> accepted. > >>> > >>> Here is the short summary; the long rationale follows after it. > >>> > >>> The proposal here is to add the following limitations to Gallium, for the > >>> intermediate semantics: > >>> 1. TGSI_SEMANTIC_NORMAL is removed, using a commit by Michal Krol that > >>> was never merged > >>> 2. Every semantic except GENERIC, COLOR and BCOLOR can only be used with > >>> semantic index 0 > >>> 3. COLOR and BCOLOR can only be used with semantic index 0-1 (note that > >>> this doesn't apply to fragment outputs) > >>> 4. GENERIC can be used with semantic indices 0-218 on any driver, if > >>> BCOLOR is not used > >>> 5. GENERIC can be used with semantic indices 0-216 on any driver, if > >>> BCOLOR IS used > >>> 6. GENERIC can be used with semantic indices 0-255 on almost all drivers > >>> (those that don't need the 0-218 limitation) > >>> 7. Some drivers may also choose to support GENERIC with arbitrary > >>> indices, but that should generally not happen > >>> > >>> The reason of this, in short, is that this maps directly to DirectX 9 > >>> SM3, which is the most problematic interface of all. > >>> > >>> The peculiar problem we have here is that we have two competing > >>> constraints that force us into choosing the exact SM3 value: > >>> 1. The VMware SVGA driver must deal with an SM3 host interface and would > >>> ideally want to directly feed the Gallium semantics to the host > >>> 2. An hypotetical DirectX 9 state tracker needs to support SM3 and would > >>> ideally want to directly feed the SM3 semantics to Gallium > >>> > >>> Note that this is not a reference to the VMware DirectX 9 state tracker, > >>> since its authors haven't provided details about its handling of shader > >>> semantics. > >>> > >>> SM3 ends up supporting 219 generic indices: 16 indices in 14 classes, > >>> minus POSITION0, PSIZE0, COLOR0, COLOR1 and FOG0 which are the only ones > >>> that wouldn't be mapped to GENERIC. > >>> However, Gallium drivers that don't benefit from having specific > >>> contraints (like svga and r600) are supposed to support 256 indices, and > >>> my nv30/nv40 work does that. > >>> > >>> The expected implementation, if no hardware support exists, is to build a > >>> list of relocations to apply to either the fragment or the vertex shader, > >>> and patch one of them at validation time to match the other. > >>> Data structures are provided in gallium/auxiliary to ease this, and try > >>> to minimize the number of times where this needs to be performed. > >>> > >>> Let's now proceed to the discussion and detailed rationale, mostly > >>> constructed by copy&pasting older messages. > >>> ... ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
