[Mesa-dev] Gallium: src_offset of pipe_vertex_element should be more restricted
jfonseca at vmware.com
Mon Apr 2 08:23:12 PDT 2012
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.
----- Original Message -----
> 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
> as the src_offset is concerned.
> On Fri, Mar 30, 2012 at 8:18 PM, Jose Fonseca <jfonseca at vmware.com>
> > ----- 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