Jump to content

  • Log In with Google      Sign In   
  • Create Account

GL3.3 Mixed FBO Resolutions Problem?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 NumberXaero   Prime Members   -  Reputation: 1459

Like
0Likes
Like

Posted 24 April 2014 - 01:29 AM

I have an FBO with 5 textures (depth and color 0,1,2,3) attached all the same size. Everything renders fine.

 

I attach another color texture, but this one is half res, no FBO completeness errors, nothing, but now rendering to just color attachment 0 and 1 which worked before, only renders to the lower left quarter of the first draw buffer, the second draw buffer still renders fine...

 

Ive only attached the extra texture to the FBO, I havent set it up for use using glDrawBuffers() or glClearBuffer*().

 

Now Ive read mixed resolution FBOs will only render (use?) the area of the smallest/minimum attached texture, thats fine, I can understand that if you render out to mixed res targets it would only fill the smallest of the attached images.

 

But I simply created a half texture and attached it to the FBO. glDrawBuffers() calls are still only targeting color0 and color1 for output. Yet it seems to think the full res color0 is half the size. Is this the correct behavior? What good is supporting mixed resolutions if smaller image use cant be managed by glDrawBuffers()?

 

Same result on NV as AMD.



Sponsor:

#2 3TATUK2   Members   -  Reputation: 730

Like
0Likes
Like

Posted 24 April 2014 - 05:54 AM

Maybe glViewport() ?



#3 pcmaster   Members   -  Reputation: 671

Like
0Likes
Like

Posted 24 April 2014 - 06:40 AM

I wouldn't say supporting mixed resolutions is a good thing at all :) If you attach several RTs and one of them is smaller, the driver maybe has no idea that the smaller one isn't actually used and it goes conservative...

 

Sounds like correct behaviour to me, maybe correct me.



#4 Hodgman   Moderators   -  Reputation: 30388

Like
2Likes
Like

Posted 24 April 2014 - 08:15 AM


Now Ive read mixed resolution FBOs will only use the area of the smallest/minimum attached texture
...

But I simply created a half texture and attached it

Doesn't that explain it?

 

If what you've read is correct, then don't attach any textures that you're not going to render to.



#5 swiftcoder   Senior Moderators   -  Reputation: 9997

Like
1Likes
Like

Posted 24 April 2014 - 08:59 AM


If what you've read is correct, then don't attach any textures that you're not going to render to.

Additionally, the general guidance is to use one FBO for each render target, rather than using glDrawBuffers to switch attachments on a single FBO.

 

FBOs are lightweight state objects - it doesn't hurt to allocate as many of them as needed, and it's a lot simpler to treat them as immutable after initialisation.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#6 samoth   Crossbones+   -  Reputation: 4783

Like
0Likes
Like

Posted 24 April 2014 - 12:28 PM

Unluckily, this is exactly according to the specification. Mixed-size attachments simply don't work (well, they do, but not as you would expect, and not in a useful way).

 

In my opinion, it's a total fuck-up as far as the spec is concerned, but quite possibly there exists hardware that can't do any different. One would think that since everything is normalized coordinates anyway, it shouldn't matter how big an attachment is, the rasterizer simply has to generate the fragments accordingly, and the fragment shader (which doesn't know anyway!) just processes them.

 

But apparently, that "the rasterizer simply..." bit is just the problem, at least on some hardware. Thus, the spec explicitly says that only the smallest common rectangle is being rendered... bleh.

 

So... not much you can do.



#7 NumberXaero   Prime Members   -  Reputation: 1459

Like
0Likes
Like

Posted 24 April 2014 - 02:08 PM

Well this is whats so confusing the previous EXT version didnt allow it, it wouldnt make a complete FBO. Now that you can attach it, I figured you could control it using glDrawBuffers() and glClearBuffer*(), which IMO would make it perfect.

A single FBO on my system supports 8 attachments, so I figured I could avoid switching/managing FBOs and use the extra color attachment points, I could understand it if mixed resolutions were set as the draw buffers, there would be an area undefined in the larger buffer, but this is almost useless unless I try something like detaching and attaching the textures to get the correct use.

 

 

 


If what you've read is correct, then don't attach any textures that you're not going to render to.

Additionally, the general guidance is to use one FBO for each render target, rather than using glDrawBuffers to switch attachments on a single FBO.

 

FBOs are lightweight state objects - it doesn't hurt to allocate as many of them as needed, and it's a lot simpler to treat them as immutable after initialisation.

 

 

Isnt that one of the main uses of glDrawBuffers()/glClearBuffer*(), not having to change FBOs or mess with attaching and detaching? You could essentially setup your FBO and fill your attachment points (supposedly with mixed resolutions), and output buffers and clearing could be managed entirely by passing arrays of integers without having to swap anything.

 

 


Now Ive read mixed resolution FBOs will only use the area of the smallest/minimum attached texture
...

But I simply created a half texture and attached it

Doesn't that explain it?

 

If what you've read is correct, then don't attach any textures that you're not going to render to.

 

 

Well, I intended to use it, but with this behavior, it went wrong early on and I never got around to it.

 

Ive read FBO switching is something that should be minimized, are they really that light now? If you were to do a custom downsample filter from 1/1 -> 1/2 -> 1/4 -> 1/8, is switching between 4 FBOs the way to go?

I dont want to get into using something that has no reasonable fallback, with the way the mixed attachments seem to work. Its a pain that it seems to have everything necessary to be managed in this way but it just doesnt work.



#8 swiftcoder   Senior Moderators   -  Reputation: 9997

Like
0Likes
Like

Posted 24 April 2014 - 02:53 PM


Ive read FBO switching is something that should be minimized, are they really that light now? If you were to do a custom downsample filter from 1/1 -> 1/2 -> 1/4 -> 1/8, is switching between 4 FBOs the way to go?

I've been using one FBO per target texture and per mipmap level where relevant for some time, and it doesn't seem to be a major performance bottleneck. I haven't seen any official sources on the matter in the last few years, but my general thought is that binding complete FBOs is likely to be cheaper than modifying and re-validating attachment state within a single FBO. The glDrawBuffers approach is probably faster still, but it limits the maximum number of buffers that can be used, and imposes the aforementioned restriction on matching sizes...

 

It is also quite likely that the performance of the various approaches varies by chipset vendor and driver implementor, so YMMV.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#9 phantom   Moderators   -  Reputation: 7279

Like
1Likes
Like

Posted 24 April 2014 - 04:40 PM

Ive read FBO switching is something that should be minimized, are they really that light now? If you were to do a custom downsample filter from 1/1 -> 1/2 -> 1/4 -> 1/8, is switching between 4 FBOs the way to go?
I dont want to get into using something that has no reasonable fallback, with the way the mixed attachments seem to work. Its a pain that it seems to have everything necessary to be managed in this way but it just doesnt work.


It's not so much switching FBOs as switching render targets of which an FBO is just a grouping of them.

Doing glDrawBuffers(...) is going to switch render targets as is switching your FBO the only difference is what state validation has to be done.

Hardware doesn't really have 'bind points' for render targets, all that happens is that some registers on the GPU are filled with 'destination address' pointers and other target data and writes go via that; so changing FBO or changing buffers is, likely, a very similar operation on the backend.

There is a chance that, if you are swapping between two buffers in the same FBO that are the same type and dimension (so 256*256 RGBA -> 256*256 RGBA for example) it might be a hair quicker to do the buffer swap vs FBO swap as the driver 'knows' via the FBO that everything is the same and won't have to state validate and could maybe upload less data (glDrawBuffers({0,1,2}) to glDrawBuffer({3,1,2}) might only upload the delta change for destinations) but I wouldn't swear to it.

If doing down sample Ping-Pong then a whole host of state is going to have to be dumped, validated and shaders setup so going from one FBO to another is likely to be the optimal route as, again, the driver has pre-validated the state (after first usage most likely). If you try to attach/detach targets then on each usage the driver has likely flagged state as 'dirty' so right before draw it'll have to do various internal checks, patches and fix ups to make sure things are correct. (It might have to, for example, patch the fragment shader to change address output calculation when going from one format and/or size to another - something you don't have to worry about but its work it has to do all the same).




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS