<div class="gmail_quote">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 <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 </blockquote><div> 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). </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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? </blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Also, it's interesting to read on the R300ToDo wiki page </blockquote><div> Thanks. ;) </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> "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 <a href="http://msdn.microsoft.com/en-us/library/bb172533%28VS.85%29.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/bb172533(VS.85).aspx</a> . 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. </blockquote><div> 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: <a href="http://cgit.freedesktop.org/~mareko/piglit/log/">http://cgit.freedesktop.org/~mareko/piglit/log/</a> </div></div> -Marek