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.

Positive index bias are trivial to implement on any hardware.

One way of implementing negative index bias would be by programing the
hardware with an artificially lower offset:

  + - - - - - - - - - - +---------------------+
  : index_bias*stride   | real vertex buffer  |
  + - - - - - - - - - - +---------------------+
  ^
  |
  pass this to hardware

but the hardware would need to have builtin support for vertex buffer
max/min index checking, to ensure only vertices inside the real range
are read. Also, the DRM would need to support these relocation with
negative offsets, and make sure that the start offset doesn't wrap
around vram start.

If the above doesn't work, then is just a matter of reading the index
buffer, make a copy of with with the right indices and use it instead.

Actually, a mixture of the above can be used.

So there is really no excuse to not support this feature unless it is
perceived to be useless.

A big user of this extension would be wine, but I've checked their
source code and they don't use it yet. Actually, they just set negative
vertex buffers offsets as a unsigned and pray that the two's complement
arithmetic inside the GL driver just works.

This feature is really used by D3D software, e.g. Google Earth on D3D.

Jose

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to