Sign in to follow this  
MichaelDeCicco

Is rendering to a texture faster than rendering to the screen?

Recommended Posts

MichaelDeCicco    205
This is really a question I'd expect to find on google, but I didn't.

So I'm building a GUI to be used with future games. Each time a GUI element is changed visually it receives the event to render itself to a texture and every frame that the element is visible the texture is rendered rather than all of the child GUI elements or characters of text.

I do it in this order:
-Enable RTT
--Render GUI element (and its children if it has any)
-Disable RTT

This made me think. Since that works without going to the screen that is limited to 60FPS, can I move the rendering code for the rest of my engine to another thread that renders to a texture to save time for doing things like full screen anti-aliasing or HDR effects and then just render the texture at 60FPS?

Share this post


Link to post
Share on other sites
Bacterius    13165
There is no such thing as rendering to the screen. You render to your backbuffer (which is a texture) however you want as fast as the hardware can manage, and then you present the finished frame which pushes it to your display, at a rate of 60Hz or whatever your desired refresh rate is.

I'm not sure what the question is - ultimately you will end up rendering your GUI texture to your frame if you want it to end up on your screen. But it is likely that the GPU will not be 100% busy while doing anti-aliasing and the likes, so in this case rendering the GUI stuff to textures in parallel might show some speed improvement. However in general GUI rendering is a negligible fraction of the total frametime so I'm not sure you'd even see a difference.

And why would you need threads? Just send the render commands asychronously, that's how graphics cards roll.

Share this post


Link to post
Share on other sites
ProfL    701
your GPU just executes one render job at a time, spreading it to multiple rendertargets will rather make it slower than faster, as it has to switch at least twice. also notice that you cannot just use two threads to render with one device, you need to create a deferred context with DX11, which just records your commands, once you're done, you still submit it from the main context, so it won't make any difference, unless you are really CPU bound while creating your draw commands.

Share this post


Link to post
Share on other sites
clb    2147
Render operations targeting an off-screen texture are not any different (on any sane platform) from rendering to the backbuffer that's going to be shown on the screen. Although one should consider:
- the backbuffer is sometimes constrained to be the size of the native display resolution. Rendering to a smaller offscreen surface first and then blitting that to the main backbuffer can reduce fillrate requirements. This kind of approach was done e.g. in the [url="http://www.nvidia.com/object/demo_vulcan.html"]nVidia Vulcan demo[/url], in which they rendered the particles to a smaller offscreen render target to reduce fillrate & overdraw impact caused by the particles.
- for UI, rendering to an offscreen surface first can give performance improvements, as it can function as a form of batching & caching. Since you can reuse the contents of an offscreen render target between frames, you can draw multiple UI elements to it and reuse the offscreen texture between frames as long as the image doesn't change. One approach could be to store an offscreen cache texture for each individual window in your UI system, and render the contents of each window to these offscreen surfaces only when the window content changes, and each frame, you will then only need to render the UI cache textures to the main backbuffer. This helps to reduce #render call counts and repeated rendering of identical content each frame.
- rendering to an screen-sized offscreen texture first, and then blitting that texture to the main backbuffer later can also dramatically impact performance. E.g. Tegra2 Android devices can do about 2.5x fullscreen blits per frame, if they are targeting 60fps. That is not much, and rendering algorithms that require temporary offscreen surfaces (glow/bloom/hdr) can often be a no-go due to device fillrate restrictions.

Share this post


Link to post
Share on other sites
japro    887
Rendering to a texture might even be slower. In OpenGL there are two kinds of possible targets for offscreen rendering: Renderbuffers and Textures. In the end it will all come down to the driver, but textures might be optimised for reading through the texture cache, which could be a disadvantage when it comes to writing to them.

Share this post


Link to post
Share on other sites
MichaelDeCicco    205
My question wasn't really GUI related. Actually, the GUI thing was completely unrelated. I just thought it would make what I was asking more clear by showing what inspired the thought.

[quote][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]There is no such thing as rendering to the screen. You render to your backbuffer (which is a texture) however you want as fast as the hardware can manage, and then you present the finished frame which pushes it to your display[/background][/left][/size][/font][/color][/quote]

That's what I meant by rendering to the screen, but I didn't hint to that at all so there's no way anybody could have known, hah.

Thank you everybody for your answers, you've enlightened me and I have nothing left to ask!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this