SDL_SetRenderTarget() and SDL_QueryTexture() efficiency

SDL Development
1

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.

2

2014-02-28 8:43 GMT+01:00 Tomeamis <tomas.zencak at seznam.cz>:

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>

Any help is appreciated.

3

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.On 2/28/2014 1:13 PM, Tomeamis wrote:

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
SDL at lists.libsdl.org
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

4

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?

Pallav Nawani wrote:

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
SDL at lists.libsdl.org
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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Also, thank you for your reply Jonas Kulla.> On 2/28/2014 1:13 PM, Tomeamis wrote:

5

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.On 3/1/2014 4:58 PM, Tomeamis wrote:

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?

Pallav Nawani wrote:
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.

On 2/28/2014 1:13 PM, Tomeamis wrote:

Quote:
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
SDL at lists.libsdl.org
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

6

2014-03-01 12:28 GMT+01:00 Tomeamis <tomas.zencak at seznam.cz>:

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.>

Pallav Nawani wrote:

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.

On 2/28/2014 1:13 PM, Tomeamis wrote:

Quote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org