OK. In that case, I think it's fine to assume these hardware limits are never
exceeded in practice, and we should just add a few assertions to catch if/when
they do.
And if we wanna be robust against this, then we should start by writing some
piglit tests that exercise it.
Jose
-
Actually, nevermind. st/mesa doesn't allow a src_offset to be greater
a stride and the maximum stride r600 supports is 2047, so we are much
more likely to fail because of a too large stride than the src_offset
(which has limit 65535). I think r600g is pretty safe right now as far
as the src_offset
Hi everyone,
I noticed the src_offset of pipe_vertex_element has 32 bits, but no
hardware can do such a large value per vertex element and it leads to
awkward workarounds in hardware drivers. To my knowledge, nv50 can
only do 12 bits and r600 can only do 16 bits. There's no such
limitation on
- Original Message -
Hi everyone,
I noticed the src_offset of pipe_vertex_element has 32 bits, but no
hardware can do such a large value per vertex element and it leads to
awkward workarounds in hardware drivers. To my knowledge, nv50 can
only do 12 bits and r600 can only do 16
On Fri, Mar 30, 2012 at 8:18 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Hi everyone,
I noticed the src_offset of pipe_vertex_element has 32 bits, but no
hardware can do such a large value per vertex element and it leads to
awkward workarounds in hardware
