SDL_Surface question.

Started by
5 comments, last by tmarques4 11 years, 2 months ago

Hello,

I'm trying to understand how SDL_surfaces work. When you set one with the SDL_HWSURFACE flag, are you storing the buffer to the GPU's memory? (Assuming there's a GPU to output video content)

If so, does the pixels parameter of the SDL_surface structure points to a position in the GPU's memory instead of the host's memory?

I tried reading the documentation http://sdl.beuc.net/sdl.wiki/SDL_Surface, but couldn't find the answer to that.

I apologise for any misunderstandings, I'm a newbie on this matter.

Thanks in advance!

Tiago.MWeb Developer - Aspiring CG Programmer
Advertisement

If so, does the pixels parameter of the SDL_surface structure points to a position in the GPU's memory instead of the host's memory?

[/quote]

The "pixels" member is only accessible while the surface is locked or if the SDL_MUSTLOCK macro evaluates as false. In the case of hardware surfaces, the idea is that if necessary SDL_MUSTLOCK would evaluate as true, and that SDL_LockSurface() may copy the pixels into a in-memory buffer where they can be modified, and SDL_UnlockSurface() would update the GPU memory version.

This means that SDL_LockSurface() and SDL_UnlockSurface() would be quite expensive calls in such scenarios.

When you set one with the SDL_HWSURFACE flag, are you storing the buffer to the GPU's memory?

[/quote]

Of course, that all depends on getting a real hardware surface to begin with. My understanding is that SDL's default backends on the major operating systems, as of version 1.2.X, do not support "hardware" surfaces. SDL 1.3/2.0 redesigned the rendering API to allow for hardware accelerated backends to be the default, but I have fallen behind on the status of this project so I don't know whether it is production ready yet. For the older version, I'd strongly recommend Bob Pendleton's SDL articles as particularly excellent.

The 'SDL_HWSURFACE' refers to hardware blitting capability - ie. the sort of thing that DirectDraw implemented 10 years ago. It's not comparable in operation or speed to fully accelerated rendering (such as projects like SFML use). These days, it's likely that SDL_HWSURFACE is the worst of both worlds - blitting speed only marginally better than when done in software, with read and blending speeds crippled by comparison.

This means that SDL_LockSurface() and SDL_UnlockSurface() would be quite expensive calls in such scenarios.

It's what I was afraid of, I don't want to move data from CPU to GPU as it's pointless and time consuming.

I'd strongly recommend Bob Pendleton's SDL articles as particularly excellent.

I've read the article about hardware surfaces (It's quite outdated) and there are some limitations, I'm having second thoughts about SDL not being the best of solution for me.

The 'SDL_HWSURFACE' refers to hardware blitting capability - ie. the sort of thing that DirectDraw implemented 10 years ago. It's not comparable in operation or speed to fully accelerated rendering (such as projects like SFML use).

I want read and write access to the buffer in video memory so I can process it with a OpenCL program, data would never be moved from one place to another. Is SFML a better solution for this? I'll look into it.

Tiago.MWeb Developer - Aspiring CG Programmer

I've read the article about hardware surfaces (It's quite outdated) and there are some limitations, I'm having second thoughts about SDL not being the best of solution for me.

[/quote]

By dated do you mean simply old, or actually out of date? I'm not sure it is dated relative to SDL 1.2.X's implementation of hardware surfaces. I'm not aware of any major backend re-work in the mean time.

I want read and write access to the buffer in video memory so I can process it with a OpenCL program, data would never be moved from one place to another.

[/quote]

Most such cross platform API's won't expose enough information to you to allow you to do this. I may be wrong, because I have not used SFML, nor OpenCL. Do you want to share the buffer between your rendering API and OpenCL?

By dated do you mean simply old, or actually out of date? I'm not sure it is dated relative to SDL 1.2.X's implementation of hardware surfaces. I'm not aware of any major backend re-work in the mean time.

Just old, it was published in 2003.

Most such cross platform API's won't expose enough information to you to allow you to do this.

I understand, such API would have to be very low level to allow such access. Since SFML provides low level access to graphics, I think It might be a solution.

Do you want to share the buffer between your rendering API and OpenCL?

That's exactly what I want to do, use OpenCL to draw images to the buffer and using the rendering API (SDL, SFML...) to just update the buffer into the screen.

Tiago.MWeb Developer - Aspiring CG Programmer

So, I've learned about OpenCL and OpenGL being able to share image data (buffers), it's perfect since what I'm looking for is implementing a post-processing shader for applying special effects to a 3D scene, it's also efficient since data doesn't have to leave GPU's memory. I don't really have to worry about SDL or SFML as they don't affect this in any way.

Thanks again for all the help!

Tiago.MWeb Developer - Aspiring CG Programmer

This topic is closed to new replies.

Advertisement