[Mesa-dev] Gallium: src_offset of pipe_vertex_element should be more restricted
Marek Olšák
maraeo at gmail.com
Mon Apr 2 08:19:16 PDT 2012
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 is concerned.
Marek
On Fri, Mar 30, 2012 at 8:18 PM, Jose Fonseca <jfonseca at 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 drivers. To my knowledge, nv50 can
>> only do 12 bits and r600 can only do 16 bits. There's no such
>> limitation on pipe_vertex_buffer::buffer_offset.
>>
>> I am proposing to change src_offset to 12 bits. Then the
>> pipe_vertex_element struct can be packed like this:
>
> D3D9 uses 16bits:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb172630.aspx
>
> D3D11 uses 32bits:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ff476180(v=vs.85).aspx
>
>
>> The Mesa state tracker change should be trivial.
>
> Could you elaborate? Would it be trivial to modify the state tracker so that it only uses 12bits all the time?
>
>> Opinions?
>
> I agree workaround this on every driver is not nice. I'm not sure it makes sense to enforce the least common denominator everywhere, or maybe just advertise the maximum in a cap. Probably most apps would not trigger anyway.
>
> Jose
More information about the mesa-dev
mailing list