Surface vs Texture - optimal usage

Stefanos_A · October 15, 2013, 10:31pm

AMD/fglrx provides a GLES + EGL implementation since 2010 or so. Please do
not restrict GLES to GLX now that we are finally moving away from this
madness (Wayland and Mir both use EGL instead of GLX.)

2013/10/15 T. Joseph Carter > Hey, I’ve got no problem limiting GLES to X on the desktop. I do imagine

some would prefer it not be so, but on a desktop system you’re probably
going to be using X anyway. GLES in that case is really a means to develop
and test your apps for embedded devices more easily.

AMD doesn’t do this? I think any video chipset produced by Intel already
uses Mesa, so that’s not a big deal. What else is there but embedded stuff
like PowerVR?

Joseph

On Tue, Oct 15, 2013 at 12:44:21PM -0300, Gabriel Jacobo wrote:

2013/10/15 T. Joseph Carter

Apparently I was wrong. I’d considered that OpenGL ES was a proper

subset
of the desktop OpenGL. Apparently that’s not true without a few
#ifdef’s.
And thought OpenGL ES v2 is closer to OpenGL 2.1, you wind up needing
OpenGL 3.x for shader compatibility.

Suddenly why there are three variants makes sense. Luckily on my end
I can test all three under Linux because VMWare accelerates Mesa well
enough. If you’re on Linux and using a binary video driver you
probably can’t.

Joseph

nVidia binaries for Linux (and SDL!) support all three variants of OpenGL
via GLX, though ES1 just barely. They’ve also incorporated EGL support
recently, restricted to X11 for now. I don’t know if this is thanks to
Valve or not, but it’s definitely a big improvement.

–
Gabriel.

_____________**

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

T_Joseph_Carter · October 15, 2013, 10:43pm

That’s really kind of up to the driver maker. As you read, NV
restricts GLES to GLX contexts. NV has been pretty receptive to
developers, though?

JosephOn Wed, Oct 16, 2013 at 12:31:21AM +0200, Stefanos A. wrote:

AMD/fglrx provides a GLES + EGL implementation since 2010 or so. Please do
not restrict GLES to GLX now that we are finally moving away from this
madness (Wayland and Mir both use EGL instead of GLX.)

going to be using X anyway. GLES in that case is really a means to develop
and test your apps for embedded devices more easily.

Stefanos_A · October 16, 2013, 6:34am

As of 331.13, Nvidia supports EGL on their drivers. See:
http://www.phoronix.com/scan.php?page=news_item&px=MTQ3NzA

2013/10/16 T. Joseph Carter > That’s really kind of up to the driver maker. As you read, NV restricts

GLES to GLX contexts. NV has been pretty receptive to developers, though?

Joseph

On Wed, Oct 16, 2013 at 12:31:21AM +0200, Stefanos A. wrote:

AMD/fglrx provides a GLES + EGL implementation since 2010 or so. Please do
not restrict GLES to GLX now that we are finally moving away from this
madness (Wayland and Mir both use EGL instead of GLX.)

going to be using X anyway. GLES in that case is really a means to
develop

and test your apps for embedded devices more easily.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

mattbentley · October 18, 2013, 10:34pm

Ryan C. Gordon wrote:

If you need to process the pixel data on the CPU.

To get it to the screen, using SDL’s 2D render API, you want an
SDL_Texture. It’s the only time you’d want an SDL_Texture, but it’s an
important time.

–ryan.

Just thought I would say thanks for this-
with sdl_image capable of loading directly to textures, pixel manipulation is really the only reason to use surfaces now.

Doug wrote:

This is actually a fairly important distinction which is almost always glossed over in SDL.

There are two ways of writing an app using SDL:

write your own 3D by hand (eg. opengl)

use the built in graphics api.
/SNIP

Thanks for this, but I thought now that SDL2 is using HWaccel’d backends, the speed was much the same as opengl/directx for simple sprite overlays etc.
Certainly the comparisons with SFML (which also uses opengl as a backend) showed an exact match of speed.
So that makes it more than enough for bullet-hell games etc? Correct me if I’m wrong, this is my understanding at the present point in time.

JonnyD · October 19, 2013, 12:32am

For many sprites using the same texture (e.g. tons of bullets), you can
gain even more performance with sprite batching. But first, profile your
code to see if you even need that.

I don’t think SDL has an implementation of sprite batching yet, but there
was talk of it previously. Of course if you use OpenGL directly, you can
do it yourself.

Jonny DOn Fri, Oct 18, 2013 at 6:34 PM, mattbentley wrote:

**

Ryan C. Gordon wrote:

If you need to process the pixel data on the CPU.

To get it to the screen, using SDL’s 2D render API, you want an
SDL_Texture. It’s the only time you’d want an SDL_Texture, but it’s an
important time. [image: Smile]

–ryan.

Just thought I would say thanks for this-
with sdl_image capable of loading directly to textures, pixel manipulation
is really the only reason to use surfaces now.

Doug wrote:

This is actually a fairly important distinction which is almost always
glossed over in SDL.

There are two ways of writing an app using SDL:

write your own 3D by hand (eg. opengl)

use the built in graphics api.
/SNIP

Thanks for this, but I thought now that SDL2 is using HWaccel’d backends,
the speed was much the same as opengl/directx for simple sprite overlays
etc.
Certainly the comparisons with SFML (which also uses opengl as a backend)
showed an exact match of speed.
So that makes it more than enough for bullet-hell games etc? Correct me if
I’m wrong, this is my understanding at the present point in time.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · October 19, 2013, 2:36am

2013/10/18, Jonathan Dearborn :

I don’t think SDL has an implementation of sprite batching yet, but there
was talk of it previously. Of course if you use OpenGL directly, you can
do it yourself.

The discussion for that wasn’t about grouping by texture though, but
outright grouping as much as possible within a single call (i.e. send
all the vertices to the GPU at the same time, instead of issuing a
draw call for every sprite).

Jonas_Kulla · October 19, 2013, 3:29am

2013/10/19 Sik the hedgehog <sik.the.hedgehog at gmail.com>

2013/10/18, Jonathan Dearborn :

I don’t think SDL has an implementation of sprite batching yet, but there
was talk of it previously. Of course if you use OpenGL directly, you can
do it yourself.

The discussion for that wasn’t about grouping by texture though, but
outright grouping as much as possible within a single call (i.e. send
all the vertices to the GPU at the same time, instead of issuing a
draw call for every sprite).

I believe that is exactly what is meant by “sprite batching” (at least L?VE
uses the term that way).

Doug1 · October 20, 2013, 3:14am

The issue isn’t speed (SDL is plenty fast), it’s functionality.

You’re fine if you want to make something like this:

If you’re doing complex rendering with dynamic effects like:

…then you probably want to use opengl or manually manage pixel buffers.

It’s up to you; but binding lots of textures and batch calling RenderCopyEx
isn’t a solution for anything other than prototyping.~
Doug.

On Sat, Oct 19, 2013 at 6:34 AM, mattbentley wrote:

**

Ryan C. Gordon wrote:

If you need to process the pixel data on the CPU.

To get it to the screen, using SDL’s 2D render API, you want an
SDL_Texture. It’s the only time you’d want an SDL_Texture, but it’s an
important time. [image: Smile]

–ryan.

Just thought I would say thanks for this-
with sdl_image capable of loading directly to textures, pixel manipulation
is really the only reason to use surfaces now.

Doug wrote:

This is actually a fairly important distinction which is almost always
glossed over in SDL.

There are two ways of writing an app using SDL:

write your own 3D by hand (eg. opengl)

use the built in graphics api.
/SNIP

Thanks for this, but I thought now that SDL2 is using HWaccel’d backends,
the speed was much the same as opengl/directx for simple sprite overlays
etc.
Certainly the comparisons with SFML (which also uses opengl as a backend)
showed an exact match of speed.
So that makes it more than enough for bullet-hell games etc? Correct me if
I’m wrong, this is my understanding at the present point in time.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

mattbentley · October 20, 2013, 10:28pm

Doug wrote:

The issue isn’t speed (SDL is plenty fast), it’s functionality.

You’re fine if you want to make something like this:
http://static.giantbomb.com/uploads/original/15/158896/2211248-2011_12_25_00005.jpg (http://static.giantbomb.com/uploads/original/15/158896/2211248-2011_12_25_00005.jpg)

If you’re doing complex rendering with dynamic effects like:
http://www.youtube.com/watch?v=2mx84JhzMUo (http://www.youtube.com/watch?v=2mx84JhzMUo)

…then you probably want to use opengl or manually manage pixel buffers.

It’s up to you; but binding lots of textures and batch calling RenderCopyEx isn’t a solution for anything other than prototyping.

Just stumbled upon this article: http://www.learn-cocos2d.com/2011/09/cocos2d-spritebatch-performance-test/

Which suggests that sprite-batching for small textures is negligibly more performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the same texture be more performant than multiple copies from multiple textures? Surely if they’re all in hardware memory at the same time it shouldn’t make a difference?

Jonas_Kulla · October 20, 2013, 10:36pm

2013/10/21 mattbentley

Which suggests that sprite-batching for small textures is negligibly more
performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the
same texture be more performant than multiple copies from multiple
textures? Surely if they’re all in hardware memory at the same time it
shouldn’t make a difference?

I don’t think it’s possible in SDL’s limited render subsystem, you’d have
to use OpenGL
directly. Also, I think you have misunderstood something. The point is to
use the same
texture for all sprites so they share one. Ideally, you want to issue as
little draw calls
(or gl calls in general) as possible, while switching textures as little as
possible.

Martin_Gerhardy · October 21, 2013, 5:50am

it is possible. you can specify the texture source rects for the render calls. that should be all you need.Am 21.10.2013 um 00:28 schrieb “mattbentley” :

Doug wrote:
The issue isn’t speed (SDL is plenty fast), it’s functionality.

You’re fine if you want to make something like this:
http://static.giantbomb.com/uploads/original/15/158896/2211248-2011_12_25_00005.jpg

If you’re doing complex rendering with dynamic effects like:
http://www.youtube.com/watch?v=2mx84JhzMUo

…then you probably want to use opengl or manually manage pixel buffers.

It’s up to you; but binding lots of textures and batch calling RenderCopyEx isn’t a solution for anything other than prototyping.

Just stumbled upon this article: http://www.learn-cocos2d.com/2011/09/cocos2d-spritebatch-performance-test/

Which suggests that sprite-batching for small textures is negligibly more performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the same texture be more performant than multiple copies from multiple textures? Surely if they’re all in hardware memory at the same time it shouldn’t make a difference?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Stefanos_A · October 21, 2013, 9:07am

Exactly, add all your sprites into a large “texture atlas” and change the
source rect to render different sprites. Lookup “texture atlas”, this is a
well-known optimization.

2013/10/21 Martin Gerhardy <martin.gerhardy at gmail.com>> it is possible. you can specify the texture source rects for the render

calls. that should be all you need.

Am 21.10.2013 um 00:28 schrieb “mattbentley” :

Doug wrote: The issue isn’t speed (SDL is plenty fast), it’s
functionality.

You’re fine if you want to make something like this:

http://static.giantbomb.com/uploads/original/15/158896/2211248-2011_12_25_00005.jpg

If you’re doing complex rendering with dynamic effects like:
http://www.youtube.com/watch?v=2mx84JhzMUo

…then you probably want to use opengl or manually manage pixel buffers.

It’s up to you; but binding lots of textures and batch calling
RenderCopyEx isn’t a solution for anything other than prototyping.

Just stumbled upon this article:
http://www.learn-cocos2d.com/2011/09/cocos2d-spritebatch-performance-test/

Which suggests that sprite-batching for small textures is negligibly more
performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the
same texture be more performant than multiple copies from multiple
textures? Surely if they’re all in hardware memory at the same time it
shouldn’t make a difference?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

mattbentley · October 21, 2013, 9:56am

Jonas Kulla wrote:

2013/10/21 mattbentley <@mattbentley (@mattbentley)>

Which suggests that sprite-batching for small textures is negligibly more performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the same texture be more performant than multiple copies from multiple textures? Surely if they’re all in hardware memory at the same time it shouldn’t make a difference?

I don’t think it’s possible in SDL’s limited render subsystem, you’d have to use OpenGL
directly. Also, I think you have misunderstood something. The point is to use the same
texture for all sprites so they share one. Ideally, you want to issue as little draw calls
(or gl calls in general) as possible, while switching textures as little as possible.

Haven’t understood how you got that out of my statement,
my question was why making multiple copies from the same texture ie. texture atlasing (yes, I read that article) is more performant than making single copies from multiple textures. To repeat my statement, if all the textures are in hardware at the same time, why is one of these techniques more performant?

Stefanos_A · October 21, 2013, 11:05am

2013/10/21 mattbentley

**

Jonas Kulla wrote:

2013/10/21 mattbentley <>

Quote:

Which suggests that sprite-batching for small textures is negligibly
more performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the
same texture be more performant than multiple copies from multiple
textures? Surely if they’re all in hardware memory at the same time it
shouldn’t make a difference?

I don’t think it’s possible in SDL’s limited render subsystem, you’d have
to use OpenGL
directly. Also, I think you have misunderstood something. The point is to
use the same
texture for all sprites so they share one. Ideally, you want to issue as
little draw calls
(or gl calls in general) as possible, while switching textures as little
as possible.

Haven’t understood how you got that out of my statement,
my question was why making multiple copies from the same texture ie.
texture atlasing (yes, I read that article) is more performant than making
single copies from multiple textures. To repeat my statement, if all the
textures are in hardware at the same time, why is one of these techniques
more performant?

Multiple copies from the same source texture => fewer state changes =>
faster.

State changes are what kills performance in this case.

Jonas_Kulla · October 21, 2013, 11:35am

2013/10/21 Martin Gerhardy <martin.gerhardy at gmail.com>

it is possible. you can specify the texture source rects for the render
calls. that should be all you need.

Okay, I guess we all have different definitions of “sprite batching” then.

Doug1 · October 21, 2013, 3:19pm

It’s not about whether you call SDL_RenderCopy() on multiple large texture
atlases or multiple small textures; you’re right; once the texture is ‘in
memory’ it’s largely irrelevant.

The point is that the more calls you make to SDL_RenderCopy() the less
efficient it is.

In the same way that calling GlBegin(); render_quad(); GlEnd(); is
inefficient; because that’s effectively what you’re doing.

Sprite batching is not possible using the standard api; there is no way
to batch dispatch geometry. The closest solution in the graphics api is
using one single texture, and calling SDL_RenderCopy() once per frame
to render the entire scene, after manually composting pixel buffers to
the texture using SDL_Surfaces.

This isn’t really sprite batching, because the composition operations are
significantly more expensive (pixel copy, cpu rotation calculations) than
simply passing geometry around, but I suppose it vaguely counts. It may
actually be faster to just repeatedly call SDL_RenderCopyEx() than doing
this, despite the inefficiencies in doing so compared to bulk dispatching
geometry.~
Doug.

On Mon, Oct 21, 2013 at 5:56 PM, mattbentley wrote:

**

Jonas Kulla wrote:

2013/10/21 mattbentley <>

Quote:

Which suggests that sprite-batching for small textures is negligibly
more performant, but for large textures makes a huge difference.
Is it possible to do sprite-batching under SDL?
Also, I’m a little confused, why would making multiple copies from the
same texture be more performant than multiple copies from multiple
textures? Surely if they’re all in hardware memory at the same time it
shouldn’t make a difference?

I don’t think it’s possible in SDL’s limited render subsystem, you’d have
to use OpenGL
directly. Also, I think you have misunderstood something. The point is to
use the same
texture for all sprites so they share one. Ideally, you want to issue as
little draw calls
(or gl calls in general) as possible, while switching textures as little
as possible.

Haven’t understood how you got that out of my statement,
my question was why making multiple copies from the same texture ie.
texture atlasing (yes, I read that article) is more performant than making
single copies from multiple textures. To repeat my statement, if all the
textures are in hardware at the same time, why is one of these techniques
more performant?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · October 22, 2013, 6:21am

2013/10/21, Doug <douglas.linder at gmail.com>:

It’s not about whether you call SDL_RenderCopy() on multiple large texture
atlases or multiple small textures; you’re right; once the texture is ‘in
memory’ it’s largely irrelevant.

Except that a state change forces the GPU to finish whatever it’s
rendering before it can move on. This severely reduces how many
polygons it can render simultaneously (and thereby performance).

Stefanos_A · October 22, 2013, 9:16am

2013/10/22 Sik the hedgehog <sik.the.hedgehog at gmail.com>:

Except that a state change forces the GPU to finish whatever it’s
rendering before it can move on. This severely reduces how many
polygons it can render simultaneously (and thereby performance).

The driver also needs to validate the new state before using it, which
makes things even worse. (Flushing the GPU command buffer may or may
not happen depending on the driver, the nature of the state change and
the phase of the moon.)

In short, this can be significantly faster:

use texture 1
use texture 1
…
use texture 2
use texture 2
…

than this:

use texture 1
use texture 2
use texture 1
use texture 2
…

Sik_the_hedgehog · October 22, 2013, 7:23pm

You’d think the driver could be doing that while the GPU is still busy
rendering…

2013/10/22, Stefanos A. :> 2013/10/22 Sik the hedgehog <@Sik_the_hedgehog>:

Except that a state change forces the GPU to finish whatever it’s
rendering before it can move on. This severely reduces how many
polygons it can render simultaneously (and thereby performance).

The driver also needs to validate the new state before using it, which
makes things even worse. (Flushing the GPU command buffer may or may
not happen depending on the driver, the nature of the state change and
the phase of the moon.)

In short, this can be significantly faster:

use texture 1
use texture 1
…
use texture 2
use texture 2
…

than this:

use texture 1
use texture 2
use texture 1
use texture 2
…

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jonas_Kulla · October 22, 2013, 9:14pm

2013/10/22 Sik the hedgehog <sik.the.hedgehog at gmail.com>

You’d think the driver could be doing that while the GPU is still busy
rendering…

I think what he said was that this is state that has to be set up
specifically
on the GPU, so it’s not just something that can be done on the CPU while
the GPU is working off other commands. I’m not sure how this even happens
on modern architectures / drivers though.