🔒 Locked

SOFTWARE_VERTEXPROCESSING vs HARDWARE_VERTEXPROCESSING

Started by cosmin Oct 31, 2005 at 4:39 AM 2 replies 950+ views

Original Post

Oct 31, 2005 at 4:39 AM

Hi everybody. I modified Text3D sample from DXSDK by extracting texture for each glyph (with GetGlyphData ) in some text and calling DrawPrimitive for each texture . On the first computer (P4 at 2 Ghz, NVidia Gefoce2 MX 400) i obtained about 25fps for 520 characters with D3DCREATE_SOFTWARE_VERTEXPROCESSING flag set. On the second computer (P4 at 3.2 Ghz, NVidia 6800 GT) running the same test I obtained about 5fps with D3DCREATE_HARDWARE_VERTEXPROCESSING and 25 fps with D3DCREATE_SOFTWARE _VERTEXPROCESSING. Is this a normal behaviour or not? Thanks in advance.

jollyjeffers

245

jollyjeffers

Oct 31, 2005 at 5:09 AM

No, that doesn't sound like typical behaviour - but it is possible.

Hardware vertex processing offloads the work to the GPU (where possible) and it should be a lot faster...

Software vertex processing is performed by the CPU, which is usually busy with other things (as well as not being optimized in the same way a GPU is) so is typically slower.

However, from your description it is possible that you're CPU limited - thus when you offload the work to the GPU it's spending most of it's time waiting for the CPU to catch up [smile]

Are you rendering every single character in it's own Draw*Primitive*() call? and swapping the texture for it as well?

Some more details on your algorithm might be useful.

Jack

cosmin

Author

cosmin

Oct 31, 2005 at 6:24 AM

Pseudo code look like this

for each char in string {	for each glyph in char	{		LPDIRECT3DTEXTURE9 pTexture=NULL;		D3DSURFACE_DESC Desc;		RECT rct,pt;		void *pVertices = NULL;		g_pFont->GetGlyphData( glyp,&pTexture,&rct,&pt);		pTexture->GetLevelDesc(0,   &Desc);		//calculate vertex params: x, y, z,tu,tv;		//...		//oops , first problem found here ! I create vertex buffer each time:		//SAFE_RELEASE(g_pVertexBuffer);		//pd3dDevice->CreateVertexBuffer( 4*sizeof(Vertex),D3DUSAGE_DYNAMIC|D3DUSAGE_WRITEONLY, Vertex::FVF_Flags,		//							D3DPOOL_DEFAULT, &g_pVertexBuffer, NULL );		//now, i got 45 fps on the first computer!		g_pVertexBuffer->Lock( 0, sizeof(g_Vertices), (void**)&pVertices, 0 );		memcpy( pVertices, g_Vertices, sizeof(g_Vertices) );		g_pVertexBuffer->Unlock();				pd3dDevice->SetTexture( 0, pTexture );		pd3dDevice->SetStreamSource( 0, g_pVertexBuffer, 0, sizeof(Vertex) );		pd3dDevice->SetFVF( Vertex::FVF_Flags );		pd3dDevice->DrawPrimitive( D3DPT_TRIANGLESTRIP,  0, 2 );		pd3dDevice->SetTexture( 0, NULL );		pTexture->Release();	}}

Seems that i found (one of) the problems.
Will remain to test the code on the second computer with HARDWARE_VERTEXPROCESSING.

Thanks.

[Edited by - Coder on October 31, 2005 9:24:13 AM]

jollyjeffers

245

jollyjeffers

Nov 1, 2005 at 7:41 AM

I have to say, that's not looking like the most efficient possible rendering loop for a string of characters [smile]

In general string processing is slow, and that's doubly true with D3D rendering... I spent months working on a text rasterizer for F1CM - taking advantage of any/every opportunity to cache values and do lazy evaluation (etc...)

I can't use it for my engine, but a vertex-shader driven text rasterizer is possible - with an exceptionally low memory footprint as well. I've not tried it on D3D9, but under D3D10 it should be possible to offload pretty much all the font work to the GPU... but that's for another day [wink]

Anyway, to help you with your problem I have a few ideas you can consider. All of them are for the algorithmic level - so you'll have to change the fundamentals:

1. Do a two-pass approach. First pass construct the necessary geometry in system memory, the second pass uploads it all in one go to the VB. That makes for a single VB lock/unlock rather than 'n' pairs of lock/unlock like you have now.

2. Related to #1 above, try to group your geometry and textures together so that you can despatch as a single draw-call. Less draw calls == better [smile]

3. Try to cache data where possible. If the text hasn't changed then just despatch it to the render queue.

4. Consider some sort hash-table style lookup for the texture coordinates and glyph information. It'll probably be faster than querying your font repeatedly.

hth
Jack

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.