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

[Marek Olšák]

Sorry about the first part of my last email, it shouldn't have been there..

On Fri, Apr 30, 2010 at 6:15 PM, 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
>

I think so. I mean these caps are useful for detecting a certain piece of hw
and it's generally a good upper bound as the shader compiler may ideally
eliminate or pair up some instructions (or unwind a few in the worst case).


> 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?
>

r500 has two flow control modes. The first one is limited to the depth of 6,
the other one seems to be unlimited but I guess it's slower.


> Also, it's interesting to read on the R300ToDo wiki page
>

Thanks. ;)


>
>  "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<http://msdn.microsoft.com/en-us/library/bb172533%28VS.85%29.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.
>

This was the next big thing in my priority list. The idea is to introduce an
"assist" driver and put all workarounds from r300g into it i.e. index buffer
workarounds, the two-sided stencil reference value workaround, even the NPOT
and shadow samplers emulation, various instructions emulation, and branch
unrolling once the r300 compiler can do a lossless TGSI->compiler->TGSI
translation (but ONLY IF there is another driver which needs these features,
the effort must be worth it). Ideally the hw driver should inherit the
assist driver context, which in turn would inherit pipe_context so that not
all functions need to be overridden (unlike failover), and then adding the
translation of incompatible vertex layouts to something a strict D3D9 hw can
consume. That is the dream.

BTW in cases when both a vertex attrib offset and stride are not a multiple
of 4, we simply align the formats e.g. R8G8 -> R8G8X8X8 (xy01). However it's
absolutely legal in GL to use e.g. R8G8B8A8 with non-DWORD aligned offset
and even if the format alone is supported, hw cannot fetch it. The same
holds for the stride, and even for the index buffer offset (ushort indices)
so these must be aligned too, meaning that simple is_vertex_format_supported
is not enough.

BTW2 I've put some vertex submission tests for unaligned vertex buffer
access here as I wanted to cover all stuff r300 cannot support:
http://cgit.freedesktop.org/~mareko/piglit/log/

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100430/da6460f2/attachment.htm>