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 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
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. > >> 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. 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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev