On Tue, Jan 26, 2010 at 4:23 AM, Jonathan Hartley <[email protected]>wrote:
> > Out of interest, I'm curious about the sort of dynamism you describe. > I worry that it's hard for an application to get hold of the results > of dynamic calculations done in this way. For example, can I tell > whether two entities moved by the GPU have collided? I worry that the > GPU-calculated dynamism lends itself well to more detailed superficial > graphics, but doesn't work very well for anything that's actually > significant in terms of application behaviour or gameplay. > > Are my concerns well-founded, or am I overlooking decent strategies > for dealing with this? > Ja, that is definitely an issue - albeit not an insurmountable one. Pulling data back across the bus is slower than sending data to the GPU - but that isn't the real problem. If you aren't careful when and what you read back, you risk stalling the entire GPU pipeline by demanding results before they are ready. You can work around this problem with another layer of indirection, i.e. copying results to an additional buffer, and reading back from that additional buffer in a frame or two, to give the computation time to finish. Asynchronous queries and fences can be leveraged to determine/control exactly when results become available. -- It is worth mentioning here that existing GPGPU applications, of which a good example is NVidia's PhysX, utilise this functionality pretty well. The CUDA PhysX driver performs all physics on the GPU, and manages to read back relevant information quickly enough to interact with the network and the rest of the game world. -- Tristam MacDonald http://swiftcoder.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
