Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (736)
Games in Android Showcase (223)
games submitted by our members
Games in WIP (813)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Shader blend modes - glCopyTexSubImage or FBO bind?  (Read 4090 times)
0 Members and 1 Guest are viewing this topic.
Offline nsigma
« Posted 2014-09-10 13:22:42 »

I'm currently looking at implementing some of the additional blend modes in Praxis LIVE within the OpenGL pipeline - ones like DIFFERENCE which need to be implemented in a shader using multiple textures.  I'm hoping to get some advice on the best way to achieve this.

All surfaces within the pipeline use texture-backed FBO's, which are cached and reused - so doing this on a full image should be quite easy - render two surfaces on to a third.  However, I'm not sure what to do in the case the user wants to render into a sub-region of a surface.  Now I probably need to get a part of the destination surface into one of the source surfaces, and I'm not sure of the best approach -

  • Bind first source texture FBO, draw destination region into it, bind destination FBO and blend textures.
  • Bind destination FBO and first source texture, use glCopyTexSubImage to get destination region into source texture, then blend textures.
  • Bind new destination FBO (like full-screen), draw areas of original destination around sub-region, then blend sub-region.
  • AN other suggestion??

I'm inclined away from option 3 as it seems to involve a lot of unnecessary rendering.  So, what's likely to be the best performing way of getting the destination FBO into another texture - option 1 involving two FBO binds, or option 2 using glCopyTexSubImage?  Or am I missing an obvious alternative?

Hope that makes sense, and thanks in advance, Neil

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline nsigma
« Reply #1 - Posted 2014-09-11 09:37:18 »

hmm .. surely someone on here has had to do this!?  persecutioncomplex

TL;DR - Which way of getting the current framebuffer into a texture is likely to work faster across different machines - using glCopyTexSubImage or using render-to-texture (bind texture FBO, draw quad, re-bind previous FBO)?

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline basil_

« JGO Bitwise Duke »


Medals: 417
Exp: 13 years



« Reply #2 - Posted 2014-09-11 10:03:35 »

i think blitting into a fbo is fastestest.

it's something like :

glTexSubImage < RTT < blit

if you want to access the default-frame-buffer, just use id 0.

- create a new FBO with same dimensions and 0 samples
- create a fitting Texture for that FBO, attach
- blit
1  
2  
3  
GL30.glBindFramebuffer(GL30.GL_READ_FRAMEBUFFER, 0); // <- 0 is the default framebuffer.
GL30.glBindFramebuffer(GL30.GL_DRAW_FRAMEBUFFER, target_fbo_id);  // <- the one just created
GL30.glBlitFramebuffer(0,0,width,height,0,0,width,height,GL11.GL_COLOR_BUFFER_BIT,GL11.GL_NEAREST);
- use texture

you can grab the other buffers like that too if you like.
GL_DEPTH_BUFFER_BIT
GL_STENCIL_BUFFER_BIT
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #3 - Posted 2014-09-11 11:15:12 »

@basil_ thanks for the input  Smiley

i think blitting into a fbo is fastestest.

OK, option 3!  Or 2.5.  I thought blit should be faster, but had discounted it because I then read some things online that suggested it wasn't faster than RTT and sometimes slower, depending on the hardware / driver.  I think this was down to RTT being more common and therefore more optimised.  Confused!  Clueless

it's something like :

glTexSubImage < RTT < blit

I assumed glCopyTexSubImage would be a slower operation in itself, but aren't FBO binds also slow?  Using the former would allow to keep the same FBO bound throughout.  Taking the need to bind an FBO twice, will RTT or blit still be faster?

if you want to access the default-frame-buffer, just use id 0.

In my particular case, this will be always be working with texture-backed FBO's.  Not sure if that will make a difference to the "right" answer.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline basil_

« JGO Bitwise Duke »


Medals: 417
Exp: 13 years



« Reply #4 - Posted 2014-09-11 11:46:53 »

OK, option 3!  Or 2.5.  I thought blit should be faster, but had discounted it because I then read some things online that suggested it wasn't faster than RTT and sometimes slower, depending on the hardware / driver.  I think this was down to RTT being more common and therefore more optimised.  Confused!  Clueless
i'm not too sure about that. i mean on the hardware i played with so far it was always the case of blit > RTT. my guess is, RTT is also about processing pixels, not just copying; maybe people mix it up.

I assumed glCopyTexSubImage would be a slower operation in itself, but aren't FBO binds also slow?  Using the former would allow to keep the same FBO bound throughout.  Taking the need to bind an FBO twice, will RTT or blit still be faster?
oops, ofc i ment CopyTexSub Smiley

nope, FBO's in general are pretty light weight. i found this on opengl wiki : http://www.opengl.org/wiki/Framebuffer_Object_Examples
Quote
1 FBO or more

Is it better to make 1 FBO and bind your texture to it each time you need to render to the texture?
An FBO itself doesn't use much memory. It is a state vector object. In terms of performance, each time you bind, the driver needs to validate the state which costs CPU time. Logically, it would be better to have 1 FBO per Render_To_Texture (RTT).
However, it has been found that you get a speed boost if your textures is the same size and you use 1 FBO for them.
If you have 10 textures that are 64x64 and 10 textures that are 512x64, make 2 FBOs. One FBO for each group.
it will be faster then copyTexImage, but if you're better with a single FBO or multiple, i don't know.

depends on how often you change the render target per frame. if you have something like 2-5 FBO's, don't bother to optimise them.

o/
Offline nsigma
« Reply #5 - Posted 2014-09-12 09:27:09 »

it will be faster then copyTexImage, but if you're better with a single FBO or multiple, i don't know.

Thanks @basil_  My inclination was to try the FBO re-bind option first, as it's the easiest to implement given what I've already got.  You've put my mind at rest a bit that this should be the right approach.

I'll be using multiple FBOs because v2 of Praxis LIVE is built on top of the Processing OpenGL renderer.  I've hacked it enough already - trying to get it to use a single FBO is probably a step further than I want to go.  My switch (from v1) is to attempt to reduce the amount of low-level GL code I have to manage!  Wink

depends on how often you change the render target per frame. if you have something like 2-5 FBO's, don't bother to optimise them.

That's all going to be user dependant - could be 2, could be 20, could be 200 - when their machine judders to a halt they'll know they've gone too far!   Grin

Praxis LIVE - hybrid visual IDE for (live) creative coding
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 
cybrmynd (120 views)
2017-08-02 12:28:51

cybrmynd (144 views)
2017-08-02 12:19:43

cybrmynd (138 views)
2017-08-02 12:18:09

Sralse (154 views)
2017-07-25 17:13:48

Archive (624 views)
2017-04-27 17:45:51

buddyBro (733 views)
2017-04-05 03:38:00

CopyableCougar4 (1260 views)
2017-03-24 15:39:42

theagentd (1239 views)
2017-03-24 15:32:08

Rule (1216 views)
2017-03-19 12:43:22

Rule (1268 views)
2017-03-19 12:42:17
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!