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