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
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
- Original
On Fri, Mar 30, 2012 at 8:18 PM, Jose Fonseca 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 drivers. To
- 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
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 pipe