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

[Keith Whitwell]

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.

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...

Keith