[Mesa-dev] RFC: gallium: Add index bias parameter to draw_elements and friends.

[José Fonseca]

On Mon, 2010-04-19 at 11:16 -0700, Keith Whitwell wrote:
> On Mon, 2010-04-19 at 09:49 -0700, José Fonseca wrote:
> > On Mon, 2010-04-19 at 06:22 -0700, Keith Whitwell wrote:
> > > On Mon, 2010-04-19 at 06:07 -0700, Marek Olšák wrote:
> > > > Unfortunately, this is supported only on r500 (i.e. not r300 nor r400)
> > > > and only when the DRM version is >=2.3.0 (i.e. kernel 2.6.34). Please,
> > > > can we make it an optional feature?
> > > 
> > > Are you sure about this?  It seems to be a long-time DX9 (and earlier?)
> > > requirement.  
> > > 
> > > I'm sure it can be made optional, though - if a state tracker absolutely
> > > required it & didn't want to implement a workaround, it could just fail
> > > to initialize on such drivers.
> > 
> > Keith,
> > 
> > This is ready to merge. My immediate concern was getting the interface
> > and basic support right, which I believe it is done.
> > 
> > I did basic testing of llvmpipe and it seems to be working, but I'd
> > appreciate an attentive pair of eye on the draw module changes.
> > 
> > I don't feel strongly about it, but I believe it does not make sense to
> > make this an optional feature of the interface: be it hardware support,
> > index translation, or fall back to draw module -- there are several easy
> > easy to get this implemented.
> > 
> > But for now Mesa does not use this, nor do hw drivers implement it (just
> > softpipe, llvmpipe, and svga do), and I see no big reason to hurry
> > changing this, as we know no user of the GL extension.
> > 
> > Negative index bias was used extensively in D3D9 when doing SWVP : IIRC
> > the D3D9 runtime would often transform the vertices in a piecewise
> > fashion into smaller vertex buffers, and reuse the indices. It is a
> > tricky we could also do in the draw module in the future, which could
> > made this feature more appealing.

I did more testing, and fixed a couple of bugs in the draw module. I
didn't hear any objection besides whether to make this a requirement or
not, which can be decided at a later time, when there is at least one
open source user of this, so I'll be merging shortly.

> Nobody ever wants to own the workaround - driver writers want to push it
> up into the state tracker, state trackers want to push it down...  And
> I'm in the middle trying to keep both sides happy...
> 
> The only way I can see to do that is to go back to the idea of a
> workaround layer between pipe driver & state tracker that takes this
> stuff away from both sides & has the extra benefit of really being a
> single location where stuff gets done.
> 
> With that in place, it could be mandatory from the state tracker's point
> of view, but optional from the drivers...

Indeed. I like that the idea the more I hear about it.

Jose