SDL hardware acceleration

[karrotsrkool]

It seems like SDL is used in so many projects that the raspberry pi would really benefit from this so I was wondering if there was any plans for it, how long it would take etc. Also if there isn't any plans for it maybe we could see what is stopping it and what we could do to help? EG a fund raiser if money is needed? Also another idea is that I don't know if there is anyone with the talent and enough time to do this but to write a library that could map the SDL function into Open GLES?
I am asking this because the pi could emulate so many games really well and it could give beginners access to graphical programming using a simple library that the industry actually use while being able to run quickly as we all know the strength of the pi is the GPU.
These are just ideas but I would love to hear what is actually going on in the foundation and broadcom. Thanks for reading and I look forward to any responses,
Andy A

[asb]

I'm interested in investigating what accelerated surfaces from the upcoming SDL 2.0 can offer. I'd suggest that as a starting point, though eventually I'll get round to digging in to it myself.

[karrotsrkool]

I don't know much about accelerated surfaces but I would assume that they are just optimized and wont help that much although it would be worth a look. The real problem is that SDL 1.2 is what the emulators are written in so that is the priority. The pi could easily run a GBA and maybe even an N64 however there just isn't the speed behind the code that the GPU can give.

[Narishma]

What functions do you think should be accelerated?
I was under the impression that SDL does it's things purely in software and isn't accelerated on any platform.

[BlackJack]

@Narishma: What is being accelerated depends on the backend.

[gordon@drogon.net]

What functions do you think should be accelerated?
I was under the impression that SDL does it's things purely in software and isn't accelerated on any platform.

I'm under the impression that if the underlying framebuffer has hardware acelleration (2D - blitter) then it can make use of it - I'm sure that even just using the GPU to copy the software copy of the framebuffer into the displaying framebufer would be an improvement... Or blitting sprites into the framebuffer and so on.

-Gordon

[realbrucest]

What functions do you think should be accelerated?
I was under the impression that SDL does it's things purely in software and isn't accelerated on any platform.

The upcoming 2.0 release will be, they say that it's around the corner already. Hopefully.

Video - Complete

• Add support for multiple windows
• Create 3D accelerated texture based rendering API
• Create API for enabling/disabling the screensaver
• Add support for selecting video mode refresh rate
• Create API for clipboard support (check out PyGame)
• Add support for multiple displays
• Add concept of viewport to fullscreen windows
• Add support for synchronizing 2D updates with vblank, using SDL_HINT_RENDER_VSYNC
• Add support for render targets

From: SDL wiki roadmap

A bit more detailed (about gfx improvements):

• Multiple windows! You don't need to have a single video surface anymore!
  This is a new API (but SDL_SetVideoMode() still exists in the
  compatibility layer).
• Multiple displays: SDL exposes details of what physical monitors are
  hooked up to a machine and lets you control them individually.
• Formal API for positioning SDL windows: it sort of comes with the
  multiple window/display support. No more setting environment variables
  for this!
• Video device enumeration: you can get an idea of what APIs and hardware
  are available to you.
• 2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with
  the 2D interfaces, so we can get acceleration on modern systems where
  X11 or DirectDraw just aren't the fast paths anymore. The framebuffer-
  oriented interfaces, like X11, are still there, though, for legacy
  platforms and hardware.
• Texture support: the 2D interfaces now concern themselves with "textures"
  and not surfaces. The assumption is that, even in 2D graphics, you now
  want to try to push all the effort to the hardware when you can,
  falling back to software where you can't. On the most basic level, this
  just means you can't get at pixel-based framebuffers without locking
  the "texture" and doing so may be much more expensive than in 1.2, but
  in many common scenarios, a well-designed program can be significantly
  more efficient in 1.3. There are some basic texture operations to offload
  common per-pixel operations to hardware so you may not have to lock the
  texture and do it yourself. This is meant to be a very simple API,
  however: those needing more, even in 2D, should consider using OpenGL
  directly.

From: over here

Obviusly Raspberry Pi would need a proper port replacing all those OpenGL calls with GLES, hard work indeed, but not so utopian.

[jethrogb]

I've got SDL 2.0 working with hardware acceleration without X. This is mostly the pandora code with modifications to make it work on the RPi. More info in http://www.raspberrypi.org/phpBB3/viewt ... 13#p194213

[gabomdq]

We are testing a patch to add "X11 free" Raspberry support to SDL 2, feel free to try it out and provide feedback here: http://bugzilla.libsdl.org/show_bug.cgi?id=2005

Thanks!

[nathanpc]

A year passed. Any updates on the situation of SDL on the Raspberry Pi?

[mrpi64]

I'd like this too. A port of SDL for Pi. I know that minecraft pi edition uses SDL, so it must be in the pi somewhere. And it's more than a year now.

[nathanpc]

Hmm, no. Minecraft Pi Edition uses LWJGL which uses OpenGL, OpenAL, etc.

[gordon@drogon.net]

I'd like this too. A port of SDL for Pi. I know that minecraft pi edition uses SDL, so it must be in the pi somewhere. And it's more than a year now.

SDL works today. It was working the day the Pi was released too.

What isn't available is an accelerated version. Even if it could get the GPU do the memory move it would make doing stuff like screen update and sprite moving much faster than it currently is. What currently happens is a highly optimised software loop on the ARM copies the screen from the memory image to the video image - which is nothing more than a big memory copy from what I see... If the GPU could do that faster, then ...

-Gordon

[nathanpc]

I was testing one of my SDL 2.0 projects called UOSC 2 weeks ago and I couldn't get better than 2 fps, the same for SDL 1.x projects like VisualBoyAdvance.

[gordon@drogon.net]

I was testing one of my SDL 2.0 projects called UOSC 2 weeks ago and I couldn't get better than 2 fps, the same for SDL 1.x projects like VisualBoyAdvance.

Something very wrong there then. I'm getting 42 fps in 1920x1080 mode and a few 100 in 640x480 mode - that's from a BASIC program just calling UPDATE (which calls SDL_Flip ()). My BASIC is still using the standard SDL 1.2 though.

Make sure you're initialising the Pi in 16bpp mode.

But maybe it's just that the ARM can't do the processing in-time? What can your program do if it never calls SDL_Flip() ?
-Gordon

[nathanpc]

SDL_Flip() doesn't exist in SDL2.

[mrpi64]

You can port SDL for openpandora, which is ARM, and supports Xwindows and opengles