Hello, I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests this), and now I've hit ProcessVertices(). As someone mentioned allready, this is a complex call, and it isn't implemented in DX7, DX8 or WineD3D.
This call does some Vertex Transformation, and depending on the App's requests, Lightning and other things. This is some math thing that is done in Software(According to msdn). On DX8 and DX9 this call is slightly different, and it looks like vertex shaders come into play.
Does anyone know any free library which implements something like this, or any internet sources on the math behind this? I haven't found anything useable with google. If I can't find anything, I'll have a look in my university's library.
One other Question: How slow is DrawStridedSlow? WineD3D uses it because of the diffuse ans specular colors. Currently I get only one useable vertex into DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their values zeroed. Without drawing anything I get 70 fps(screen refresh rate, expected), with the 6 Vertices I get 1.5 fps. Is this normal for DrawStridedSlow()? Might this be because of drawing 2 triangles with useless vertices? Or might something else be wrong?
Stefan
One other Question: How slow is DrawStridedSlow? WineD3D uses it because of the diffuse ans specular colors. Currently I get only one useable vertex into DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their values zeroed. Without drawing anything I get 70 fps(screen refresh rate, expected), with the 6 Vertices I get 1.5 fps. Is this normal for DrawStridedSlow()? Might this be because of drawing 2 triangles with useless vertices? Or might something else be wrong?
It's slow, but not *that* slow in my experience. When testing with an about three years old DX8 game on an Athlon Tb 1,33 Ghz & Geforce 4400 Ti I get about 15-20 fps when using drawStridedSlow and about 40-45 fps when using drawStridedFast. Curiously, changing graphics settings doesn't seem to have much of an effect on performance.
On the subject of drawStridedSlow / color fixups, something I was wondering about is how feasible it would be to use vertex shaders to fix the colors. I guess it would require reimplementing pretty much the entire fixed function pipeline as shaders. I also don't know what the impact would be on performance, but I seem to remember reading somewhere that modern gfx cards don't have a real fixed function pipeline anymore and that the drivers use the programmable pipeline to implement much of that functionality anyway. I've got no idea how reliable that claim is though.
On Saturday 29 October 2005 13:17, H. Verbeet wrote: <snip>
On the subject of drawStridedSlow / color fixups, something I was wondering about is how feasible it would be to use vertex shaders to fix the colors. I guess it would require reimplementing pretty much the entire fixed function pipeline as shaders. I also don't know what the impact would be on performance, but I seem to remember reading somewhere that modern gfx cards don't have a real fixed function pipeline anymore and that the drivers use the programmable pipeline to implement much of that functionality anyway. I've got no idea how reliable that claim is though.
VS Impact only for color channels reorder will be ... null :) As you said "modern gfx cards don't have a real fixed function pipeline anymore"
But the big problem is handling VS to support the maximum of the slow cases for each gfx card (who don't perform the same way for tricky VS code)
Regards, Raphael
--- "H. Verbeet" hverbeet@gmail.com wrote:
One other Question: How slow is DrawStridedSlow? WineD3D uses it because of the diffuse ans specular colors. Currently I get only one useable vertex into DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their values zeroed. Without drawing anything I get 70 fps(screen refresh rate, expected), with the 6 Vertices I get 1.5 fps. Is this normal for DrawStridedSlow()? Might this be because of drawing 2 triangles with useless vertices? Or might something else be wrong?
There will be an even bigger difference when vertex buffer objects are used.
On the subject of drawStridedSlow / color fixups, something I was wondering about is how feasible it would be to use vertex shaders to fix the colors. I guess it would require reimplementing pretty much the entire fixed function pipeline as shaders.
That was my plan, the shader needs to performs all the vertex transforms as well as the colour fixups. I aleady got some software fixup code for people without shaders
I also don't know what
the impact would be on performance, but I seem to remember reading somewhere that modern gfx cards don't have a real fixed function pipeline anymore and that the drivers use the programmable pipeline to implement much of that functionality anyway. I've got no idea how reliable that claim is though.
The impact shouldn't be too high, and once the shaders been written it can be cached, TG seem to be getting reasonable performance from softare using JIT complication of shaders.
___________________________________________________________ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com
Hi,
On Friday 28 October 2005 23:34, Stefan Dösinger wrote:
Hello, I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests this), and now I've hit ProcessVertices(). As someone mentioned allready, this is a complex call, and it isn't implemented in DX7, DX8 or WineD3D.
The better way is to implement it using Vertex Shader. Anyway you can provide a "software emulation" using a pre-compiled IWineD3DVertexBuffer (you will be supported by wine on HW in few time, when we'll submit support for vbo extension) (Sorry i have no time now to commit it, maybe Oliver...)
One other Question: How slow is DrawStridedSlow? WineD3D uses it because of the diffuse ans specular colors. Currently I get only one useable vertex into DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their values zeroed. Without drawing anything I get 70 fps(screen refresh rate, expected), with the 6 Vertices I get 1.5 fps. Is this normal for DrawStridedSlow()? Might this be because of drawing 2 triangles with useless vertices? Or might something else be wrong?
Yes it's really slow (and usefull for debugging but we use it too many times). but many of the slow cases can be (another time) supported by DrawStridedFast when vbo support will come.
Example: for specular/diffuse color, whe can adapt VB strided content to OpenGL format on Unlock and restore D3D content on Lock if we have an VB on input who should be the majority of the cases.
Stefan
Keep the god job :)
Regards, Raphael
--- Stefan Dösinger stefandoesinger@gmx.at wrote:
Hello, I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests this), and now I've hit ProcessVertices(). As someone mentioned allready, this is a complex call, and it isn't implemented in DX7, DX8 or WineD3D.
This call does some Vertex Transformation, and depending on the App's requests, Lightning and other things. This is some math thing that is done in Software(According to msdn). On DX8 and DX9 this call is slightly different, and it looks like vertex shaders come into play.
Does anyone know any free library which implements something like this, or any internet sources on the math behind this? I haven't found anything useable with google. If I can't find anything, I'll have a look in my university's library.
It may be possible to use the feedback buffer and get OpenGL to do all the work http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glfu....
The majority of the math is fairly simple matrix transforms, OpenGL extensions usually have all the math required. http://oss.sgi.com/projects/ogl-sample/registry/
One other Question: How slow is DrawStridedSlow? WineD3D uses it because of the diffuse ans specular colors. Currently I get only one useable vertex into DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their values zeroed. Without drawing anything I get 70 fps(screen refresh rate, expected), with the 6 Vertices I get 1.5 fps. Is this normal for DrawStridedSlow()? Might this be because of drawing 2 triangles with useless vertices? Or might something else be wrong?
1.5fps seems very slow, even for DrawStridedSlow but DrawStridedSlow will be superseded as soon as the colour fixups are in place.
Oliver..
Stefan
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Hello,
It may be possible to use the feedback buffer and get OpenGL to do all the work http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glf unc02_3m42.asp.
The majority of the math is fairly simple matrix transforms, OpenGL extensions usually have all the math required. http://oss.sgi.com/projects/ogl-sample/registry/
The feedback buffers are definitly interesting here. I've noticed that the D3D7 IDirect3DVertexBuffer7::ProcessVertices and D3D9 IDirect3DDevice9::ProcessVertices are very similar, but they have a few differences. While the D3D9 funktion is related to hardware vertex shaders, the D3D7 funktion does it's job explicitly in software(according to the DX7 sdk). The reason is that vertex shaders were simply not available in when DX7 came out.
The calculations that DX7's ProcessVertices can perform are clipping, lighting, some extent thing and transforming the vertices. Most things (or all) can be done with OpenGL extentions and Vertex shaders. However, I'd suggest a software implementation for DX7 as a fallback for cards which don't have shaders and cards which don't have the necessary extensions.
I have to read the data locations from the vertex buffers to do anything with them. Can I do the following: SetStreamSource(Input VB); primitiveConvertToStridedData(input_strided); SetStreamSource(Output VB); primitiveConvertToStridedData(output strided);
// Do calculations
/*SetStreamSource(NULL) if necessary */
Is this possible, or will it cause problems?
1.5fps seems very slow, even for DrawStridedSlow but DrawStridedSlow will be superseded as soon as the colour fixups are in place.
I guess this happens because I am poking completely senseless values into drawPrimitive, like sensless colors and texture coordinates. The numbers are not 0, as I thought first.
Stefan
On Sun, Oct 30, 2005 at 02:15:56PM +0100, Stefan Dösinger wrote:
However, I'd suggest a software implementation for DX7 as a fallback for cards which don't have shaders and cards which don't have the necessary extensions.
Well, if you go this way, that means writing an almost complete (except for texturing) OpenGL implementation of the geometry pipeline.
This is why I did it (for the only application actually using it) via the current 'hack'.
After, one can always imaging lifting code from Mesa or TinyGL to do that, but I would really investigate if the current hack is not enough for all games out there.
Lionel
An update to the drawStridedSlow thing: With my a little bit less senseless ProcessVertices implementation, the framerate increased from 1.5 fps to 4.5 fps(CPU0@600 Mhz) and from 2 fps to 6 fps (CPU0@1400 mhz). So I guess it's the garbage I am sending to drawPrimitives that makes it so slow.
-
H. Verbeet -
Lionel Ulmer -
Oliver Stieber -
Raphael -
Stefan Dösinger