I am currently working on a software rasterizer as a school assignment.
I started with copying image buffers to the screen, but the performance is already terrible.
At the moment I tried both glDrawPixels and copying the data to a texture and then drawing a quad on screen with that texture.
Sending data to the GPU every frame is just so incredibly slow.
I've had this same problem before with a software raytracer and I'm getting tired of it.
Something so simple should not take up so much of your application's performance.
So here is my question: What is the fastest way of getting my image data on the screen?
I'm willing to go all out.
I don't care which API I have to use as long as it works on Windows.
So I don't mind whether it's OpenGL, DirectX or even the Windows API.
So the only restrictions are:
- Works on Windows
- Uses C++
So if you know a quick way of doing this, or even just an idea of something that might be worth a try, please tell me.
Fastest way of getting image on screen
How about drawing a fullscren quad? Dont have time to explain, but should be straigthforward to find information
In terms of APIs, I like PixelToaster. It's extremely simple, and cross-platform. I'm not sure what it does under-the-hood, except that on Windows it uses DirectX 9.
I would suggest using a GPU/CPU texture (Staging texture in DX10/11). I can explain how to do it in 11 because I've done something similar.
For DX11:
1) Map (Lock) the texture.
2) Write your data in one memset.
3) Unmap (Unlock) the texture.
4) Copy the resource to a render target. (You may be able to do this directly to the back buffer. I don't remember.) Use: CopyResource (or was it CopySubresource?)
5) Render the render target to the back buffer.
This is off the top of my head.
For DX11:
1) Map (Lock) the texture.
2) Write your data in one memset.
3) Unmap (Unlock) the texture.
4) Copy the resource to a render target. (You may be able to do this directly to the back buffer. I don't remember.) Use: CopyResource (or was it CopySubresource?)
5) Render the render target to the back buffer.
This is off the top of my head.
Drawing a fiullscreen quad is one tried and trusted way. If the texture needs to change every frame (e.g. you're rendering video) you need to look into dynamic texture updates, of course.
With OpenGL you need to make sure that your glDrawPixels parameters match your framebuffer format, otherwise it will need to go through a software conversion layer. On Windows this typically means that format param needs to be GL_BGRA and the type param needs to be GL_UNSIGNED_INT_8_8_8_8_REV. The more typically seen GL_RGB/GL_UNSIGNED_BYTE combination will always be slow as framebuffers are typically 32-bit (with the extra 8 unused). The params I gave are good enough to run fullscreen video at fast framerates on most hardware.
With Direct3D 9 you could create a device with D3DPRESENTFLAG_LOCKABLE_BACKBUFFER in it's present parameters flags member, then lock the back buffer and write the image data directly in. This should be more than fast enough so long as that's all you're doing every frame.
With OpenGL you need to make sure that your glDrawPixels parameters match your framebuffer format, otherwise it will need to go through a software conversion layer. On Windows this typically means that format param needs to be GL_BGRA and the type param needs to be GL_UNSIGNED_INT_8_8_8_8_REV. The more typically seen GL_RGB/GL_UNSIGNED_BYTE combination will always be slow as framebuffers are typically 32-bit (with the extra 8 unused). The params I gave are good enough to run fullscreen video at fast framerates on most hardware.
With Direct3D 9 you could create a device with D3DPRESENTFLAG_LOCKABLE_BACKBUFFER in it's present parameters flags member, then lock the back buffer and write the image data directly in. This should be more than fast enough so long as that's all you're doing every frame.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
