Christoph, I don't see a patch for the st/mesa program translation code to check that we don't exceed the limit. Were you doing to take care of that too?
I guess we're assuming that the max number of generic inputs == max number of generic outputs. I think that's OK until a counter case appears. -Brian On 12/17/2010 05:28 AM, Keith Whitwell wrote: > 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 > . > ------------------------------------------------------------------------------ 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
