Jump to content

  • Log In with Google      Sign In   
  • Create Account


DrawIndexedPrimitive & ATI driver


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
23 replies to this topic

#21 grosvenor   Members   -  Reputation: 149

Like
0Likes
Like

Posted 17 July 2012 - 07:29 AM

@Hodgeman:
I have looked directly at the index values in the V&I-buffers. As far as I can see, the conditions you state are met.
Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ... Posted Image
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure.

@mhagain:
Right, that would work. But nothing I am too eager to do. And the ATI driver problem might still remain.

Sponsor:

#22 Hodgman   Moderators   -  Reputation: 29302

Like
0Likes
Like

Posted 17 July 2012 - 07:46 AM

Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ... Posted Image
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure

Yeah I agree, a overly generous range seems like it should be safe, and practice tells us that it is safe (so far Posted Image)

For curiosity, the only hypothetical situation I can think of is:
Let's assume we're only using D3DPT_TRIANGLELIST and DrawIndexedPrimitive.
The driver is emulating vertex processing, but it's done by a worker thread. The PrimitiveCount param is summed over a whole frame, and the sum multiplied by 3 to calculate the maximum number of verts required. To allow maximum latency, a whole-frame vertex buffer is constructed of the previously calculated max size. At the end of a frame (after this buffer's been created) the worker thread is alowed to start.
For each DrawIndexedPrimitive call, the worker thread reserves a portion of the whole-frame vertex-buffer equal to the draw-call's NumVertices value (the number of unique verts to be processed). With a generous NumVertices value, the whole-frame vertex-buffer will be depleted before all draw-calls have been processed, which will result in either: GPU-readable vertex allocation to extend a ring-buffer, complex CPU/GPU ring-buffer stalling routines, or when those fail or aren't implemented: simply aborting the draw-call in (silent) error...

Edited by Hodgman, 17 July 2012 - 07:52 AM.


#23 grosvenor   Members   -  Reputation: 149

Like
0Likes
Like

Posted 17 July 2012 - 11:09 AM

Interesting theory. Not entirely impossible that somebody would do something like this. Posted Image

#24 quiSHADgho   Members   -  Reputation: 325

Like
0Likes
Like

Posted 25 July 2012 - 09:00 AM

In case someone has the same problem and is reading this: I had the same problem myself today with my DX9 Engine and the Mobility Radeon 2600. Upgrading the Catalyst Driver from 12.4 to the 12.6 Beta for HD2000, HD3000 and HD4000 seams to fix it for me.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS