When will ATI properly support FBOs?

Ah, FBOs will do the same thing on Nvidia hardware as well. Since FBOs can be bound as a render target, running on multiple GPUs requires the driver to make some hard guarantees about consistency. Which GPU gets which part of the FBO? Tiled, equal split, dynamic split? Then you'll have lots of bus traffic to get each GPU updated. If you aren't using the data as a render target, just make it a texture... To do GPGPU stuff, we treat each board as a separate processor and deal with the data movement ourselves.

There is no reason that the driver folks couldn't support this, but they have to provide a general solution that probably won't be near the performance you could do on your own. I'd be worried about massive GL state flushes and lots of extra data transfer to make everything work consistently.

 

I dont render to the FBO, I just create it.

I don't have a Nvidia-SLI machine, so I cannot try on Nvidia hardware.

I understand that it could be complex to support Crossfire optimisation when the application is rendering in a FBO, but when the application is rendering in the back buffer of the main context they should not disable the optimisation. If it works with the PBuffer, it should work with the FBO.

 

Here's the deal with FBOs. The original extension was intended to be a complete replacement for those clunky annoying things called pbuffers. Unfortunately, the FBO spec came up short in a couple of areas. I don't know if the working group felt rushed or got lazy or what, but two major things were left out.

The first thing left out was practical support for stencil buffers. The original spec allows you to attach a depth buffer to an FBO, and it allows you to attach a separate stencil buffer to an FBO, but it doesn't support the mixed depth/stencil 24/8 format. The problem is that all modern hardware only supports the mixed 24/8 format and not separate depth and stencil buffers. Therefore, in the original FBO implementations, it is impossible to use a stencil buffer because you'll always get an FRAMEBUFFER_UNSUPPORTED error. If you have an engine that, say, uses stencil shadows, then you're out of luck.

The second thing left out was multisampling support. Fortunately, the ARB has recognized both of these shortcomings, at least on paper, and has now released the EXT_packed_depth_stencil and EXT_framebuffer_multisample extensions. Nvidia got the EXT_packed_depth_stencil extension implemented a while ago, and support for the EXT_framebuffer_multisample extension is expected soon.

ATI is another story, though. ATI has consistently expressed a complete lack of interest in implementing either of the new extensions even though they had people in the working groups that designed them. I've been asking for EXT_packed_depth_stencil for about a year because my engine uses stencil shadows. The best answer that I've gotten so far was at GDC this year when I talked to one of ATI's engineers in person. He said "maybe late this year, but no guarantees". After I explained my situation to him (needing packed depth/stencil for shadows) and that I would have to use pbuffers on ATI hardware to get a depth/stencil buffer, he kept trying to convince me that I should use FBOs because they're much faster and easier to use! No f***ing sh*t, sherlock! But have you been listening to me? ... Sorry, got a little frustrated there.

So ATI continues their long tradition of half-assed OpenGL support. I remember when Doom3 was in early development and it exposed so many bugs in ATI's drivers that John Carmack shunned the company for six months. It seems that only a major developer with a lot of influence over what graphics cards people buy can get ATI to actually care about their driver quality. I wish there was some recourse for everyone who isn't Id Software. It'd be nice if we could sue ATI and get a court order commanding them to implement depth/stencil, but now I'm dreaming.

 

You might want to vent more steam here:

3D Nature and Partners Declare ATI drivers Unsuitable for Professional Visualization

It does look like ATI would rather OGL didn't exist, doesn't it?

Jawed

 

Heya, Eric. . .welcome to B3D.

Don't be a stranger. . .

http://www.terathon.com/eric/index.html

 

The lack of "Ati is working on new OpenGL Magic Drivers, written from scratch for the latest cards! They'll release them soon!" is disturbing.

And Eric, welcome to the board.

 

Isn't OGL the defacto workstation standard? Or is that changing as well?

Because if it isn't changing, then your comment just can't be true. They have repeatedly stated their intention to grab an increasing share of that highly lucrative market.

Now, we can discuss, if you'd like, why that won't happen until/unless they get their OGL in shape. . . but I don't think its possible they can have both of those positions.

 

3D Workstation is a broad term, though.
If we encompass all the differnt type of 3D WS, then yeah, OGL is still the standard.

Now, if we take a look at the 3D Worstations (basically PCs) used in most content creation art pipelines, used to run 3DSMAX and the like, DirectX, while not dominant at all for the moment being, could inded be a substitute I'd guess.

 

Reading thru that link, is it at all an interesting distinction that they keep saying "Radeon" and "Catalyst". . .rather than FireGL? They are talking about "professional realtime visualization" development, but not pointing at ATI's professional solution. Do we know if these same problems occur in FireGL drivers? It almost sounds like there might be attempt here to get FireGL-like functionality at Radeon prices. . . or possibly they just worded it badly.

 

Props to you guys for detecting the "catalyst" factor, and making these "professionals" look silly.

And me an arse for taking it at face value

Jawed

 

If you can get that through, could you start another one to get my NV40 Purevideo fixed so it can do all the stuff it was marketed to do before NV realized it was broken? Thanks

 

I declare that my hammer sucks as a screwdriver.