[Mesa-dev] RFC: Expose vertex/fragment progam limits in Mesa state tracker

[Corbin Simpson]

On Fri, Apr 30, 2010 at 9:15 AM, José Fonseca <jfonseca at vmware.com> wrote:
> I agree that deriving coarse grained caps from fine grained sounds
> better.
>
> Anyway, I'll apply this on until we have better caps system inplace, as
> it's better than nothing.
>
> One more question, having the design of these new fine caps in mind, are
> the gl_program_constants sufficient?
>
>  MaxNativeInstructions
>  MaxNativeAluInstructions
>  MaxNativeTexInstructions
>  MaxNativeTexIndirections
>  MaxNativeAttribs
>  MaxNativeTemps
>  MaxNativeAddressRegs
>  MaxNativeParameters
>
> One obvious omission relative to D3D9 caps are max dynamic control flow
> depth. These are not mentioned in the R300ToDo wiki page. Does hardware
> we care about has such limitations too?
>
> Also, it's interesting to read on the R300ToDo wiki page
>
>  "Vertex formats GL_*INT and GL_DOUBLE are not supported. GL_*SHORT is
> supported only for 2- and 4-component vertex attributes, and GL_*BYTE
> only for 4-component attributes. All individual vertex attribute fetches
> must be DWORD-aligned."
>
> This clearly resembles the
> http://msdn.microsoft.com/en-us/library/bb172533(VS.85).aspx . It
> appears that modifying draw module or a new library for software vertex
> fetch/emit without vertex shading would be useful for a lot of hardware.
>
> Jose
>
> On Thu, 2010-04-29 at 14:12 -0700, Marek Olšák wrote:
>> I was getting at your former idea of replacing caps with feature
>> levels. I was also commenting on the proposed José's patch that we
>> should have fine-grained
>>
>> On Thu, Apr 29, 2010 at 10:09 PM, Zack Rusin <zackr at vmware.com> wrote:
>>         On Thursday 29 April 2010 15:44:35 Marek Olšák wrote:
>>         > On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin
>>
>>         >  <zackr at vmware.com<mailto:zackr at vmware.com>> wrote: It seems
>>         like all we'd
>>
>>         >  really need is relate those things to
>>         > the feature/api levels it exposes and document it.
>>         >
>>         > Feature levels are a pretty bad match for D3D9-level
>>         chipsets since the
>>         >  hardware is so divergent that you'd need a lot of them.
>>         You'd have at
>>         >  least 2 (I can come up with 3) levels just for r300g, at
>>         least two levels
>>         >  for nvfx, and another two levels for the i9xx drivers,
>>         provided all these
>>         >  drivers want to expose precisely every feature they can
>>         support. There is
>>         >  a reason for having shader models sm2.0, sm2.0a, and
>>         sm2.0b. Moreover this
>>         >  Microsoft idea is _absolutely_ useless for a GL driver. I
>>         like more the
>>         >  idea of having util functions for deriving feature levels
>>         from a set of
>>         >  caps rather than caps from feature levels.
>>
>>
>>         I'm not sure if you actually looked what Jakob committed,
>>         because what you're
>>         describing is what he's done. Or are you arguing against some
>>         part of that
>>         implementation?
>>
>> I was assuming you'd wanted to return to your former idea of replacing
>> caps with feature levels rather than having what Jakob has committed.
>> If it's not the case then ignore my message.
>>
>> Also looking at José's patch I think we should have fine-grained
>> queries ideally for each shader stage separately if we want it to be
>> useful at all. The proposed minimum limits are fine except that
>> MaxNativeTexIndirections for ps2.0 should be 4. For an idea how the
>> shader limits vary for r300g, please see the two tables at the
>> beginning of this page:
>> http://dri.freedesktop.org/wiki/R300ToDo
>
> Vertex formats GL_*INT and GL_DOUBLE are not supported. GL_*SHORT is
> supported only for 2- and 4-component vertex attributes, and GL_*BYTE
> only for 4-component attributes. All individual vertex attribute fetches
> must be DWORD-aligned.

Yeah, one of the things I wanted to do was provide a shadow-VBO setup,
and the primary consumer would be the driver (or state tracker, with
caveats). At VBO bind, call a translate-on-steroids function that
creates shadow VBOs as needed, filled with formats that the driver can
handle.

The caveat, of course, is that the state tracker would need access to
the list of PIPE_FORMATs the driver can use in VBOs before it could
call this function itself.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>