Is wine reporting the right value for MaxVertexBlendMatrices ?

Alex Jackson awj_in_japan at
Sat Feb 9 23:34:49 CST 2008

> That said, GL_ARB_vertex_blend is not very common. Only MacOS supports it, and 
> it is software emulated there. The Linux ATI driver used to support it until 
> ATI switched to a different codebase. So this constant ends up beeing 0 
> almost everywhere. The extension was dropped in favor of vertex programs, 
> since vertex programs appeared shortly after vertex blending and no gl app 
> was using it at this time. On Windows drivers emulate vertex blending using 
> vertex shaders.
> I am not sure if 0 is the correct value to return in case of no vertex 
> blending support. What happens if you set it to 1? 1 would be a reasonable 
> default as well, because we're still able to transform vertices with one 
> matrix(ie, unblened transformation). It could also be that this game silently 
> expects vertex blending to be supported: For one part, all dx8+ cards support 
> this feature on Windows, and on older cards Windows has software vertex 
> processing which can perform blending in a slow, but working fashion.
> I have a patch for software emulated vertex blending somewhere, but I dropped 
> it because I didn't come across an app which uses this function. Maybe its 
> time to revive it, and continue the work on a fixed function replacement 
> shader.

Even on Windows, no OpenGL implementation that I know of supports GL_ARB_vertex_blend other than ATI's (and as you've pointed out, the new OpenGL stack that the Radeon HD's use on Windows and that all Radeons now use on Linux has dropped it).

History lesson:  Both GL_ARB_vertex_blend and D3D vertex blending are historically tied to a specific piece of hardware: the original ATI Radeon (GL_ARB_vertex_blend started out as GL_ATI_vertex_blend).  Presumably, due to ATI's historically spotty OpenGL driver performance (okay, "historically" is being kind to ATI), any game developer who wanted to use the Radeon's capabilities targeted their game for D3D rather than OpenGL.   Consequently, when nVidia released the GeForce 3 (the first video card with vertex shaders) they did implement D3D vertex blending via shaders in their D3D driver (since games were using it, and it wouldn't do if the "new" GF3 couldn't handle effects that the "old" Radeon could), but they didn't bother to implement it in their OpenGL driver, even though ATI had gotten it ARB-approved some months before the GF3 came out,  since no games/apps were using it.  The other video hardware makers (the few that were left by the DX8 era) followed NV's example: implement D3D vertex blending via shaders or in software (for entry-level and onboard hardware without vertex shaders), but don't bother with GL_ARB_vertex_blend since no one uses it.

The upshot is that GL_ARB_vertex_blend is an ARB extension In Name Only; it's effectively ATI-only--and even ATI has abandoned it now.  On the other hand, D3D vertex blending is universally available on modern and semi-modern hardware regardless of maker, and it looks like even some D3D9 games still use it instead of using vertex shaders.  So it's better for WINE to implement vertex blending via vertex programs rather than depending on GL_ARB_vertex_blend.



-------------- next part --------------
An HTML attachment was scrubbed...

More information about the wine-devel mailing list