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