Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Wicked Ewok

I don't get why having multiple drawindexedprimitive seems to stall

This topic is 5400 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

so let me be a bit brief as I can, I did two experiments using vertex and index buffers. The common base for both experiments is this: 27 DrawPrimitive calls of 801 vertices(267 triangles - TRIANGLELIST ) Shader = fixedcolor out + a little vertex tweening here is what both tests look like: http://www.mojo9.com/~wickedewok/scene.gif Now, for test A, I put all 801*27 vertices in 1 STATIC( don't change it after the first init ) vertex buffer and used DrawPrimitive() to render them all. This is the throughput I get: FPS:71.3466 Number of vertices/second = 1.54301e+006( divide by 3 to get tris/sec ) number dps: 27 verts: 801 Now for test B, I compact the 801 vertices into roughly 535 vertices and put them in the one Static vertex buffer. I use a Static index buffer to look into this vertex buffer. I render with 27 DrawIndexedPrimitive() calls and here is my result: FPS:7.18518 Number of vertices/second = 155394 number vbs: 27 verts: 801 Ok what looks a litle weird are the numbers, I'm getting almost exactly 10 times less than the first experiment, but here is the calllist from D3D Spy for both: testa) http://www.mojo9.com/~wickedewok/VertexBufferRender.gif testb) http://www.mojo9.com/~wickedewok/IndexBufferRender.gif I have not done anything else in between. When I use 1 Drawprimitive for both test A and B and 9000 vertices, there throughput is identical. Only when I start using many DPs and DIPs do two methods diverge in speed. any ideas? thanks -Marv edit- links were fine, just the link headings were copied and pasted, fixed now. [edited by - Wicked Ewok on February 28, 2004 8:10:55 PM]

Share this post


Link to post
Share on other sites
Advertisement
How big is your vertex buffer in the DrawPrimitive case?

From the vertex stride passed to SetStreamSource and the StartVertex value used in the first DrawPrimitive call in that D3DSpy dump, it''s gotta be over 13 megabytes in size. Does that sound odd? Are you sure that those calls are actually succeeding?

Share this post


Link to post
Share on other sites
Are you using StartIndex and NumVertices to only transform the part of the VB you''re interested in for that draw? If you''re using software vertex processing, you might be transforming the entire VB 27 times a frame. So, you''re doing 26 times the work, 27 times a frame, or 702 times the work.

Why do we see a lock/unlock of your VB just before you draw? (And why did you give the same URL for both test cases?)

Share this post


Link to post
Share on other sites
don - vertices are 20 bytes each, I have 801 vertices per drawprimitive(27), so that means I have 801*27*20 bytes worth of vertices = 432540 bytes which is what you see from my drawprimitives. I don''t understand how you got 20 MB for the size of my vertexbuffer. The Drawprimitive calls all retur S_OK, otherwise the program would assert itself. The D3DSpy dump should also show that.

Namethatnobodyelsetook - From what I understand, and how I implemented it, start index refers to the offset in vertices that is added to each value in the indexbuffer when calling DP. NumVertices is the number of vertices used during that render from StartVertex( or basevertex ). Relative to the basevertex, the minindex has to equal 0 since I''m not adding to the Indexbuffer index manually, each call gets indices valued between 0~535. NumVertices is 535 and I am not skipping vertices( You know drawindexedprimitive has to be the most confusing thing to use, tell me if I''m getting anything wrong ).

The lock and unlock at the end is for text rendering. It''s that chunk of square geometry on the render there, for some reason, it picks up from my shader since I set the effect class not to save renderstates, but that''s another bug that I''ll have to get to. The text rendering doesn''t stall, it''s consistant in both experiments.

Thanks for the replies.

-Marv

Share this post


Link to post
Share on other sites
I apologize, I don''t know where I got the idea that the StartVertex parameter to DrawPrimitive was a vertex count instead of a byte offset (maybe from DrawIndexedPrimitive). As if that wasn''t bad enough, I also misinterpreted the ''20'' in the call to SetStreamResource as a hex value instead of decimal.

I''ll just keep quiet now and go take my meds.

Share this post


Link to post
Share on other sites
You know what don, you are right! I didn''t realize that the vertex offset is not in bytes, I had thought they were. So in this case, the Vertex experiment seemed to only draw the first mesh( and since the meshes are all almost identical except for a slight translation I didn''t notice it visually ). The vertex experiment drawing only one mesh made it seem faster, when in all cases I was getting roughly the same output. DP calls S_OK as long as there seems to be reasonable data, it doesn''t really check. Sorry about that.

Share this post


Link to post
Share on other sites
Well now, this bites even worse than I thought. I'm getting an average throughput of 92940 tris/sec with all triangles drawn. I made it so the mesh translations actually show. There should not be overdraw since the meshes are all on the same z, and I set the zfunc to always fail if equal or less( I disabled this and reverted to default ( only fail on less ) and throughput dropped dramatically. So what's the deal..this is like the fastest set up I can think of to render the system. I'm getting really low framerates. Some stats:

130 TOTAL FPS: 1257 FPS:9.66923
Number of vertices/second = 278822 ~= 92940 tris/sec
number DP calls: 4 verts: 7209

117 TOTAL FPS: 956 FPS:8.17094
Number of vertices/second = 176713 ~= 58900 tris/sec
number vbs: 27 verts: 801

Anything from the D3DSpy dump that someone can pick up from?
Thanks again, don and namenobodyelsetook

[edited by - Wicked Ewok on February 28, 2004 12:26:11 AM]

Share this post


Link to post
Share on other sites
More tests reveal that this app is extremely fill-rate limited. The depth testing doesn't seem to help 'that' much. There is a noticable difference with and without it( without ~= 5FPS before while with ~=10 FPS ). But after reducing the meshes, and making sure they don't overlap at all so that depthtesting won't really effect it, I got a sudden leap in rendering rate:

FPS:104.566
Number of vertices/second = 3.01526e+006 ~= 1.0 million tris/sec
number DP calls: 4 verts: 7209

I am now very puzzled...maybe I didn't set depthtesting up correctly and it's only 'half' working?..Better front to back rendering maybe( but technically..since the zfunc is made 'less', if anything is z1==z2, it won't draw that pixel, and all these vertices have exactly the same z value..
I'm running this on a geforce 3

-Marv

[edited by - Wicked Ewok on February 28, 2004 12:49:02 AM]

Share this post


Link to post
Share on other sites
finally..something that looks better, here's a screenshot of my final render:
http://www.mojo9.com/~wickedewok/ScreenRender.jpg

here are some stats:
FPS:101.373
Number of vertices/second = 6.5772e+006 ~= 2,192,400 tris/sec
== (109,000tris/frame @ 60 FPS)
number vbs: 3 verts: 21627

System: GF3, Athalon 1.2Ghz
Screensize = 640x480
Rendering technique = optimal trilist vbuffer using indexed buffer,TRILISTs(probably can get more optimal with TRISTRIPS),tweening vertexshader,colorout pixelshader,1 VB, 1 IB, 3 DP calls@7000+ tris per call.
culling is off, zenabled, zfunc = less

made sure mathematically that all tris are still on the screen and none overlap. Overdraw was causing all the performance hits on my GF3. Sigh..

-Marv

[edited by - Wicked Ewok on February 29, 2004 3:49:33 AM]

Share this post


Link to post
Share on other sites
quote:

Number of vertices/second = 6.5772e+006 ~= 2,192,400 tris/sec
== (109,000tris/frame @ 60 FPS)



Are you sure your numbers are correct ? 109 000 tris / frame @ 60 fps == 6.5 MTris/sec, not 2.

Y.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!