On Mon, Apr 19, 2010 at 08:40:07PM +0200, José Fonseca wrote: > On Mon, 2010-04-19 at 10:57 -0700, Marek Olšák wrote: > > According to ARB_draw_elements_base_vertex, the index clamping should > > be done prior to adding the index offset and r500 seems to implement > > it the same way, which kinda makes the clamping useless here. > > Does it really change anything? Issue 8 says the follow is true: > > start <= indices[i] <= end > > instead of > > start <= indices[i] + basevertex <= end > > If you want the produce the later with the former, then we could program > the hardware/gallium with > > MAX(start - basevertex, 0) <= indices[i] <= end - basevertex > > and if (end - basevertex < 0) then just skip the draw, as all vertices > would be clamped. > > Or am I missing something here? > > But you raise a very good point regarding the minIndex/maxIndex > semantics that I was neglecting. I'll make sure the > documentation/implementation is consistent with the D3D APIs and GL > extension. > > > To my knowledge there is no way to implement hw-accelerated, negative > > index offsets other than with the r500-specific register. We already > > do tons and tons of fallbacks and some crucial ones are still missing > > so I wouldn't like to implement more of them than is absolutely > > necessary. > > I could turn your argument around: s/fallbacks/capabilities checks/. > > Anyway, I don't care about this particular piece of functionality. It's > basic in D3D9/D3D10, but hardly relevant on GL. > > Jose >
As r300g has never been used as a production driver AFAIK i think we could simply say that once it becomes such it will need at least 2.6.34 kernel and thus avoid any fallback either in r300g or in gallium core. Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
