[SDL] Sound lag with winmm

ANTA antarcticstation at gmail.com
Thu Sep 25 11:40:25 PDT 2014


Knowledge about how the rendering pipeline works backs it up. :)

GPUs operate asynchronously from CPUs and are heavily pipelined. When you issue a rendering command (e.g. glDrawArrays, or SDL_RenderCopy in SDL_Render) the CPU will submit the command to a queue which the GPU works through on its own time, after the CPU has generated lower level command(s) from the function call.

Because of all the pipelining, GPUs tend to be 1 (or more) whole frames behind the CPU, in terms of what’s being processed right at that moment. What that means for things like reading back the texture data from the CPU to the GPU, is that the CPU will have to block until the GPU has completed that entire frame’s worth of work before the readback function can return, since the GPU generally processes commands in a FIFO manner.

There are ways to make the transfer asynchronous rather than blocking, but you would still need to wait 1+ frames before the data is available. At 60fps, 1 frame is about 17 milliseconds. That would be 17ms just to get a single texel's color from a texture in the GPU.

As mentioned earlier, SDL_Texture objects that were created with the streaming flag keep a CPU-side copy of their data, so this isn’t a problem for that case.

On Sep 2, 2014, at 9:01 PM, Mason Wheeler <masonwheeler at yahoo.com> wrote:

> You know, every time this topic comes up, I see that same warning come out again and again, and nothing to back it up.
> 
> How great an impact does it have on rendering performance?  What is the expected data transfer rate from GPU->main memory like?  How does it differ between different video card models?
> 
> Mason
> 
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140903/f8dae07f/attachment-0002.htm>


More information about the SDL mailing list