<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 17.12.2010 17:54, Marek Olįk wrote:
<blockquote
cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Fri, Dec 17, 2010 at 4:32 PM, Brian
Paul <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Christoph,<br>
<br>
I don't see a patch for the st/mesa program translation code
to check<br>
that we don't exceed the limit. Were you going to take care
of that too?<br>
<br>
</blockquote>
</div>
</blockquote>
I didn't plan to for now, at least nothing beyond making the state
tracker return an error if possible, and removing/modifying a
certain comment mentioned below.<br>
<br>
<blockquote
cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
I guess we're assuming that the max number of generic inputs
== max<br>
number of generic outputs. I think that's OK until a counter
case<br>
appears.<br>
</blockquote>
<div><br>
The way I understand it is that the max number of generic
outputs is equal to the max number of generic inputs in the
next shader stage (the same logic applies to some other shader
caps too). I guess we need to use get_param to determine which
shader stages are supported by the driver to know which one is
next. The name </div>
</div>
</blockquote>
The problem is that (apart from the linked GL program case) you
cannot know which stage is next until validation time.<br>
You have the same problem with the existing
PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS - nv50's vertex shaders can
output more variables to geometry shaders than they can to vertex
shaders.<br>
<br>
Maybe MAX_GENERIC_INDEX should be a non-shader specific cap - for
nvc0 the value is the same everywhere, and for hardware that only
has VP and FP as well.<br>
<br>
<blockquote
cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><b>PIPE_SHADER_CAP_MAX_GENERIC_INPUT_INDEX</b> would be
less ambiguous (still not perfect though).<br>
<br>
</div>
</div>
</blockquote>
I thought about using something even more verbose, like
PIPE_SHADER_CAP_MAX_GENERIC_INPUT_SEMANTIC_INDEX.<br>
<br>
<blockquote
cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>However I don't believe in usefulness of this new cap, at
least not without some serious state tracker work. I don't
consider failing to translate a shader if some CAP is too low
particularly useful.<br>
<br>
</div>
</div>
</blockquote>
The use of the cap is to prevent state tracker writers from thinking
they're free to use GENERIC[0,96,8911] or whatever random numbers
they like and rely on pipe drivers to ensure at all costs that
linkage will be correct.<br>
<br>
In mesa/st I see the comment<br>
/* Actually, let's try and zero-base this just for<br>
* readability of the generated TGSI.<br>
*/<br>
So I guess someone thought it would be ok to start at some
unspecified high index. Such random behaviour makes it really hard
to get ARB_separate_shader_objects features (which galliums assumed
pipe drivers would be able to do anyway from the start) sanely.<br>
<br>
---<br>
<br>
So, maybe we can do without this cap. Maybe it would be better to
just mandate that the GENERIC index be less than
PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS after all.<br>
<br>
Christoph<br>
<br>
<blockquote
cite="mid:AANLkTinw2rcKeChVCmm0y6dHb33QezUW3sgcw+q1jFUo@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>(posting to mesa-dev as well)<br>
<br>
Marek<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<font color="#888888"><br>
-Brian<br>
</font>
<div>
<div><br>
<br>
On 12/17/2010 05:28 AM, Keith Whitwell wrote:<br>
> Christoph,<br>
><br>
> This looks good. Thanks for bringing this back to
life.<br>
><br>
> Keith<br>
><br>
> On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller
wrote:<br>
>> On 12/14/2010 12:36 PM, Keith Whitwell wrote:<br>
>>> On Mon, 2010-12-13 at 12:01 -0800, Christoph
Bumiller wrote:<br>
>>>> I want to warm this up again adding nvc0
and<br>
>>>> GL_ARB_separate_shader_objects to the
picture.<br>
>>>><br>
>>>> The latter extends
GL_EXT_separate_shader_objects to support user<br>
>>>> defined varyings and guarantees well
defined behaviour only if<br>
>>>> - varyings are declared inside the
gl_PerVertex/gl_PerFragment block the<br>
>>>> blocks match exactly in name, type,
qualification, and (most<br>
>>>> significantly) declaration order.<br>
>>>> - varyings are assigned matching location
qualifiers:<br>
>>>> like: layout(location = 3) in vec4 normal<br>
>>>> "The number of input locations available
to a shader is limited."<br>
>>>><br>
>>>> So, I propose to (loosely) identify
GENERIC semantic indices with these<br>
>>>> location qualifiers and let the pipe
driver set a limit on the allowed<br>
>>>> maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS,
and not demand to at least<br>
>>>> support 219 of them - nvc0 offsers 0x200
bytes for generic inputs/outputs).<br>
>>><br>
>>> This sounds fine actually. We kicked this
around before& I was<br>
>>> basically ok with the last iteration of the
proposal, but this seems ok<br>
>>> too.<br>
>>><br>
>>> As far as I can tell from a gallium
perspective you're really just<br>
>>> proposing a new pipe cap _MAX_INPUTS
(actually _MAX_GENERIC_INDEX would<br>
>>> be clearer), which the state tracker
thereafter has to respect?<br>
>>><br>
>>> That would be fine with me.<br>
>> First attempt at a patch introducing such a cap
attached.<br>
>><br>
>>><br>
>>>> My motivation is mostly that the hardware
routing table for shader<br>
>>>> varyings that was present on nv50 has
been removed with nvc0 (Fermi).<br>
>>>> And I'm glad, because filling 4 routing
tables (since we have 5 shader<br>
>>>> types now) is somewhat annoying. And so
applying relocations to shaders<br>
>>>> - it can be done, it's probably not too
time consuming, but it's just<br>
>>>> plain *unnecessary* (and thus stupid) for
OpenGL.<br>
>>>><br>
>>>> Now about d3d9 ...<br>
>>>> 1. don't care, I don't see a d3d9 state
tracker<br>
>>>> 2. <a moz-do-not-send="true"
href="http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx"
target="_blank">http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx</a><br>
>>>> says "n is an optional integer between 0
and the number of resources<br>
>>>> supported" - what "supported" means here
isn't clear to me, but, I<br>
>>>> didn't find any example where someone
used something OpenGL doesn't have<br>
>>>> (like COLOR2).<br>
>>>> 3.<br>
>>>> <a moz-do-not-send="true"
href="http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics"
target="_blank">http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics</a><br>
>>>> says "Input semantics are similar to the
values in the D3DDECLUSAGE."<br>
>>>> and<br>
>>>> DECLUSAGE sounds like you're limited to
sane values.<br>
>>><br>
>>> I think you're on the right track with (1)...
It's fairly pointless<br>
>>> trying to discuss code here which isn't
public& I don't think people<br>
>>> need to be worrying about what may or may not
be important for code they<br>
>>> can't see.<br>
>>><br>
>>> I know this idea previously got tied up with
speculation about what a<br>
>>> DX9 state tracker might or might not require,
but in retrospect I wish<br>
>>> I'd been able to steer conversation away from
that.<br>
>>><br>
>>> The work on closed components may drive a lot
of the feature development<br>
>>> and new interfaces, but there's usually
enough flexibility that this<br>
>>> sort of cleanup isn't a big deal.<br>
>>><br>
>>><br>
>>> Keith<br>
>>><br>
>>>> Not sure if anyone wants to think about
this issue at this time (since<br>
>>>> implementation of
ARB_separate_shader_objects is probably far in the GL4<br>
>>>> future), but I'd be happy about any
comments.<br>
>>>><br>
>>>> Regards,<br>
>>>> Christoph<br>
>>>><br>
>>>> On 04/13/2010 12:55 PM, Luca Barbieri
wrote:<br>
>>>>> This patch series is intended to
resolve the issue of semantic-based shader linkage in
Gallium.<br>
>>>>> It can also be found in the
RFC-gallium-semantics branch.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> These limitations are added to allow
an efficient implementation for both hardware lacking
special support and hardware having support but also
special constraints.<br>
>>>>><br>
>>>>> Note that this does NOT resolve all
issues, and there are quite a bit left to future
refinement.<br>
>>>>><br>
>>>>> In particular, the following issues
are still open:<br>
>>>>> 1. COLOR clamping (and floating point
framebuffers)<br>
>>>>> 2. A linkage table CSO allowing to
specify non-identity linkage<br>
>>>>> 3. BCOLOR/FACE-related issues<br>
>>>>> 4. Adding a cap to inform the state
tracker that more than 219 generic indices are provided<br>
>>>>><br>
>>>>> This topic was already very
extensively discussed.<br>
>>>>> See <a moz-do-not-send="true"
href="http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html"
target="_blank">http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html</a>
for some early inconclusive discussion around an early
implementation that modified the GLSL linker (which is NOT
being proposed here)<br>
>>>>> See <a moz-do-not-send="true"
href="http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12016.html"
target="_blank">http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12016.html</a>
for some more discussion that seemed to mostly reach a
consensus over the approach proposed here.<br>
>>>>> See in particular <a
moz-do-not-send="true"
href="http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12041.html"
target="_blank">http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12041.html</a>
.<br>
>>>>><br>
>>>>> That said, I'm going to try to repeat
all information here, partially by copy&pasting from
earlier messages.<br>
>>>>> This message should probably be
adapted into gallium/docs if/when this is accepted.<br>
>>>>><br>
>>>>> Here is the short summary; the long
rationale follows after it.<br>
>>>>><br>
>>>>> The proposal here is to add the
following limitations to Gallium, for the intermediate
semantics:<br>
>>>>> 1. TGSI_SEMANTIC_NORMAL is removed,
using a commit by Michal Krol that was never merged<br>
>>>>> 2. Every semantic except GENERIC,
COLOR and BCOLOR can only be used with semantic index 0<br>
>>>>> 3. COLOR and BCOLOR can only be used
with semantic index 0-1 (note that this doesn't apply to
fragment outputs)<br>
>>>>> 4. GENERIC can be used with semantic
indices 0-218 on any driver, if BCOLOR is not used<br>
>>>>> 5. GENERIC can be used with semantic
indices 0-216 on any driver, if BCOLOR IS used<br>
>>>>> 6. GENERIC can be used with semantic
indices 0-255 on almost all drivers (those that don't need
the 0-218 limitation)<br>
>>>>> 7. Some drivers may also choose to
support GENERIC with arbitrary indices, but that should
generally not happen<br>
>>>>><br>
>>>>> The reason of this, in short, is that
this maps directly to DirectX 9 SM3, which is the most
problematic interface of all.<br>
>>>>><br>
>>>>> The peculiar problem we have here is
that we have two competing constraints that force us into
choosing the exact SM3 value:<br>
>>>>> 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<br>
>>>>> 2. An hypotetical DirectX 9 state
tracker needs to support SM3 and would ideally want to
directly feed the SM3 semantics to Gallium<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>> Data structures are provided in
gallium/auxiliary to ease this, and try to minimize the
number of times where this needs to be performed.<br>
>>>>><br>
>>>>> Let's now proceed to the discussion
and detailed rationale, mostly constructed by
copy&pasting older messages.<br>
>>>>> ...<br>
><br>
><br>
><br>
>
------------------------------------------------------------------------------<br>
> Lotusphere 2011<br>
> Register now for Lotusphere 2011 and learn how<br>
> to connect the dots, take your collaborative
environment<br>
> to the next level, and enter the era of Social
Business.<br>
> <a moz-do-not-send="true"
href="http://p.sf.net/sfu/lotusphere-d2d"
target="_blank">http://p.sf.net/sfu/lotusphere-d2d</a><br>
> _______________________________________________<br>
> Mesa3d-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Mesa3d-dev@lists.sourceforge.net"
target="_blank">Mesa3d-dev@lists.sourceforge.net</a><br>
> <a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/mesa3d-dev"
target="_blank">https://lists.sourceforge.net/lists/listinfo/mesa3d-dev</a><br>
> .<br>
><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Lotusphere 2011<br>
Register now for Lotusphere 2011 and learn how<br>
to connect the dots, take your collaborative environment<br>
to the next level, and enter the era of Social Business.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/lotusphere-d2d"
target="_blank">http://p.sf.net/sfu/lotusphere-d2d</a><br>
_______________________________________________<br>
Mesa3d-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Mesa3d-dev@lists.sourceforge.net"
target="_blank">Mesa3d-dev@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/mesa3d-dev"
target="_blank">https://lists.sourceforge.net/lists/listinfo/mesa3d-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>