SDL_SetRenderTarget() and SDL_QueryTexture() efficiency

[Tomeamis]

So, I recently started rewriting my game for SDL2, and I read this in the Migration guide: "Round trips--reading data back from textures--can be painfully expensive".

I'd like to know whether rendering SDL_Texture to another SDL_Texture using SDL_TEXTUREACCESS_TARGET and SDL_SetRenderTarget() then SDL_RenderCopy()ing the texture and resetting the render target constitutes a "round trip" or if it all just happens on the GPU and therefore has no huge implact on performance.

Also, does SDL_QueryTexture() have to access the VRAM, or is the info about the texture in the RAM?

Any help is appreciated.

[Jonas Kulla]

Post by Tomeamis
So, I recently started rewriting my game for SDL2, and I read this in
the Migration guide: "Round trips--reading data back from textures--can be
painfully expensive".
I'd like to know whether rendering SDL_Texture to another SDL_Texture
using SDL_TEXTUREACCESS_TARGET and SDL_SetRenderTarget() then
SDL_RenderCopy()ing the texture and resetting the render target constitutes
a "round trip" or if it all just happens on the GPU and therefore has no
huge implact on performance.
Also, does SDL_QueryTexture() have to access the VRAM, or is the info
about the texture in the RAM?

As you can see in the source code [1], QueryTexture only retrieves
information from the RAM resident struct, so there are no flushes
like one would expect from eg. glGet().

[1] https://hg.libsdl.org/SDL/file/d123fc5d02bc/src/render/SDL_render.c#l569

Post by Tomeamis
Any help is appreciated.

[Pallav Nawani]

No, that's not a 'round trip'. In your example, though, I see no reason
to reset the render target afterwards.
SDL doesn't allow you to read data from VRAM anyway.

Post by Tomeamis
So, I recently started rewriting my game for SDL2, and I read this in
the Migration guide: "Round trips--reading data back from
textures--can be painfully expensive".
I'd like to know whether rendering SDL_Texture to another SDL_Texture
using SDL_TEXTUREACCESS_TARGET and SDL_SetRenderTarget() then
SDL_RenderCopy()ing the texture and resetting the render target
constitutes a "round trip" or if it all just happens on the GPU and
therefore has no huge implact on performance.
Also, does SDL_QueryTexture() have to access the VRAM, or is the info
about the texture in the RAM?
Any help is appreciated.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Tomeamis]

Thanks. The renderer reset would only happen when I want to draw the final texture to the screen. I guess I could have made that clearer, but I didn't think it mattered that much.

Also, I thought that SDL_RenderReadPixels does read from VRAM as it reads the actual pixels, does it not?

Post by Pallav Nawani
No, that's not a 'round trip'. In your example, though, I see no reason
to reset the render target afterwards.
SDL doesn't allow you to read data from VRAM anyway.

Post by Tomeamis
So, I recently started rewriting my game for SDL2, and I read this in
the Migration guide: "Round trips--reading data back from
textures--can be painfully expensive".
I'd like to know whether rendering SDL_Texture to another SDL_Texture
using SDL_TEXTUREACCESS_TARGET and SDL_SetRenderTarget() then
SDL_RenderCopy()ing the texture and resetting the render target
constitutes a "round trip" or if it all just happens on the GPU and
therefore has no huge implact on performance.
Also, does SDL_QueryTexture() have to access the VRAM, or is the info
about the texture in the RAM?
Any help is appreciated.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Also, thank you for your reply Jonas Kulla.

[Pallav Nawani]

My Bad. In fact SDL_RenderReadPixels() does what you say.

I was thinking of SDL_LockTexture() and how the pixels it returns are
not pixels from VRAM, but pixels from RAM.

Post by Tomeamis
Thanks. The renderer reset would only happen when I want to draw the
final texture to the screen. I guess I could have made that clearer,
but I didn't think it mattered that much.
Also, I thought that SDL_RenderReadPixels does read from VRAM as it
reads the actual pixels, does it not?
No, that's not a 'round trip'. In your example, though, I see no reason
to reset the render target afterwards.
SDL doesn't allow you to read data from VRAM anyway.
So, I recently started rewriting my game for SDL2, and I read this in
the Migration guide: "Round trips--reading data back from
textures--can be painfully expensive".
I'd like to know whether rendering SDL_Texture to another SDL_Texture
using SDL_TEXTUREACCESS_TARGET and SDL_SetRenderTarget() then
SDL_RenderCopy()ing the texture and resetting the render target
constitutes a "round trip" or if it all just happens on the GPU and
therefore has no huge implact on performance.
Also, does SDL_QueryTexture() have to access the VRAM, or is the info
about the texture in the RAM?
Any help is appreciated.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Also, thank you for your reply Jonas Kulla.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Jonas Kulla]

Post by Tomeamis
Thanks. The renderer reset would only happen when I want to draw the
final texture to the screen. I guess I could have made that clearer, but I
didn't think it mattered that much.
Also, I thought that SDL_RenderReadPixels does read from VRAM as it reads
the actual pixels, does it not?

Yes, 'SDL_RenderReadPixels()' is the equivalent to 'glReadPixels()' and
will read actual pixel data from the currently bound render target (either
the screen, or a TARGET texture), ie. from VRAM.

The reason why it's rather hard to answer your first question is because,
firstly, SDL has many render backends (GL, GLES, D3D, PSP, SW etc.),
which can all behave slightly differently (in fact, ReadPixels isn't
implemented
on PSP at all), and even if you were to nail it down to only GL, driver
differences will come into play. I have heard that some drivers may cause
an implicit glFlush() whenever the framebuffer binding is changed, but I
have no evidence for it.
With something like ReadPixels, the result of the function depends on all
previous draw calls definitely having finished, so you are 100% sure to get
stalls in the render pipeline, although for SW it's again only a memcpy.

Post by Tomeamis
No, that's not a 'round trip'. In your example, though, I see no reason
to reset the render target afterwards.
SDL doesn't allow you to read data from VRAM anyway.
So, I recently started rewriting my game for SDL2, and I read this in
the Migration guide: "Round trips--reading data back from
textures--can be painfully expensive".
I'd like to know whether rendering SDL_Texture to another SDL_Texture
using SDL_TEXTUREACCESS_TARGET and SDL_SetRenderTarget() then
SDL_RenderCopy()ing the texture and resetting the render target
constitutes a "round trip" or if it all just happens on the GPU and
therefore has no huge implact on performance.
Also, does SDL_QueryTexture() have to access the VRAM, or is the info
about the texture in the RAM?
Any help is appreciated.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Also, thank you for your reply Jonas Kulla.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org