> Either way, I anticipate having to build a function that, given a > pipe_vertex_element and pipe_vertex_buffer, and a list of acceptable > pipe_formats, internally magically modifies things inside so that all > resulting VBOs are safe for HW.
As I mentioned on IRC, it may be possible to avoid this, as long as the GPU supports fp32, some flavor of int8, and some flavor of int16: 1. For int8/int16 add a vertex shader constant and add a mul to multiply input by it. Use that to correct the scaling. 2. Use another couple of constants and sge+mad to correct signedness (v = v + (v >= c0) * c1; where e.g. c0 = 0x80 and c1 = -0x100) 3. For fp16, use ->is_vertex_format_supported to not expose the GL extension 4. For int32 and fp64 (and fp16 if the app uses it despite the extension not being advertised), fallback to the draw module. Using int32, fp64 or unsupported fp16 is rare and stupid, and the application deserves it. The constants may be inlined to trade off vertex shader length for number of shaders to compile. This should cover all cards: nv30, nv40 and r300 are covered, i915 uses draw, and DX10 gpus should support everything. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
