[Mesa-dev] Gallium: src_offset of pipe_vertex_element should be more restricted
maraeo at gmail.com
Fri Mar 30 13:27:00 PDT 2012
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:
> D3D11 uses 32bits:
Weird. I am wondering whether they used UINT because it's a commonly
used type, or whether there was some real reason.
>> 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?
Src_offset is non-zero only when the vertex elements are interleaved.
In such a case, src_offset = attrib->pointer - the lowest address of
all vertex attribs. In the function is_interleaved_arrays, I would
just add another restriction saying that the difference between each
attrib pointer and the lowest address must be less than (1 << 12). It
could be easily done with a CAP too.
> 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.
The reason I proposed this is that I'd like to decouple vertex buffers
from vertex elements in r600g. Right now we have a workaround such
that if src_offset is too large, we just add it to buffer_offset of
pipe_vertex_buffer. As a result of that, interleaved vertex attribs
must be converted into separate ones in the driver.
More information about the mesa-dev