I’m trying to find out why ATI 9250 doesn’t support FBO.
I finally got to update driver (to Cat. 5.8), for the single reason I expected to get FBO support, which seems to have been supported on 9500 and later from at least 5.7. I think the following emoticon best express my reaction when I found out it didn’t: :eek:
I had expected FBO to be supported for just about all hardware, back to at least Radeon 7000 and TNT1. Am I missing something, such as a requirement in the FBO spec that older hardware can’t provide?
There is no such requirement. It’s just that ATI doesn’t want to have those features on old cards. Your card could do GL_ARB_vertex_shader, too, but ATI doesn’t expose the functionality in their driver. AFAIK you can get FBO with your card using the free DRI (as opposed to the proprietary ATI ones) Linux drivers.
It’s not that simple, supporting new features on older cards means driver engineers wind up running around supporting a boat load of stuff on products that were shipped years ago and the whole process grinds to a halt, and you don’t get spiffy new features & hardware as rapidly and driver quality suffers accross teh board. The complexity of maintaining drivers for a product line is bad enough without the overheads of adding that stuff to older cards.
I’m sure ATI would love you to have FBO on all their old cards (really they don’t give a crap about losing a sale to your old card, using stuff like FBO and other fancy new features might even make you crave more performance), it’s just work to implement and test it all on all products. They’re kinda busy fighting to the death with NVIDIA…
So there is, as I expected, nothing technically missing from the h/w, but the case of a vendor not supporting its own h/w? If so, this sucks.
With vendor support like this, for a product in this case less than one year old (*), it’s almost as if they don’t want developers to use the first and only cross-platform extension for e.g. RTT for the only cross-platform 3D API. An extension that, to add insult to injury, is documented to have the potential to be faster than the platform-exlusive extensions.
I wonder how long it is until they stop supporting X800…
(*) I know the design is older, but this card has a firmware dated 2004/07/05, and I sure hasn’t updated it.
So there is, as I expected, nothing technically missing from the h/w, but the case of a vendor not supporting its own h/w?
That has not yet been determined. On the surface, it looks like this hardware should be able to do what FBO needs. But we don’t know if there are or are not issues with the spec that may make it fail.
For example, on hyper-old cards like the TNT’s, I wouldn’t be too surprised if the hardware was simply unable to write to swizzled textures. And I wouldn’t be too surprised if it were unable to read from non-swizzled textures. Thus, it would be unable to bind any texture as a render target, or to use the results of an RTT operation as a texture.
Now, the fact that TNT2’s implement WGL_ARB_render_texture seems to work against that theory. However, the ARB_RT extension isn’t enough. Remember, ARB_RT doesn’t permanantly store the render texture. It doesn’t affect any texture object permanantly, so it is really just using the pbuffer. So, if the TNT were unable to write directly to a swizzled texture, but were able to texture from an unswizzled one, then in order to implement FBO, there would need to be some kind of special “unswizzled” or “renderable” internal texture format. Which, of course, FBO does not define.
I’m not saying that this is the case; it could very well be that the different revisions of hardware make it prohibitively time consuming/expensive to bother. But I think it’s not entirely accurate to dismiss the possibility out of hand that FBO simply can’t work on older cards.
I stubbornly refuse to add platform-specific code to something intended to be cross-platform. That path leads to the dark side, and D3D…
But I think it’s not entirely accurate to dismiss the possibility out of hand that FBO simply can’t work on older cards.
The wording from the spec makes me think otherwise:
“Dependencies: OpenGL 1.1 is required.”
As that’s the only listed dependency, in combination with the observation that ARB_RT is supported, it seems to me even almost a decade old h/w should be able to support this.
The spec itself even seems to allow for this to be implemented as render-to-FB followed by copy to texture (emphasis added): The “render to texture” semantics of this extension are similar to performing traditional rendering to the framebuffer, followed immediately by a call to CopyTexSubImage.
However, by using this extension instead, an application can achieve the same effect, but with the advantage that the GL can usually eliminate the data copy that would have been incurred by calling CopyTexSubImage.
Sure, it would be about as slow as doing it manually, but at least I (and others) wouldn’t have to support multiple code-paths in the apps. I hope this didn’t give some vendors the wrong idea here, that doing it this way could be considered a good solution, unless the h/w absolutely can’t support it in any other way.
My gut feeling tells me otherwise, but OK, I’m willing to give the vendors the benefit of a dubt that there actually may be some inherent technical obstacles of pre-9500 and pre NV3x h/w preventing inclusion of FBO.
The wording from the spec makes me think otherwise:
“Dependencies: OpenGL 1.1 is required.”
As that’s the only listed dependency, in combination with the observation that ARB_RT is supported, it seems to me even almost a decade old h/w should be able to support this.
I don’t think you understand the purpose of that line. It isn’t to denote a level of expected hardware functionality (OpenGL version numbers don’t work like D3D versions). It is simply to say that the functionality extended by FBO is only that which was available since OpenGL 1.1. It doesn’t mean that 1.1 implementations should be able to use it.
The spec itself even seems to allow for this to be implemented as render-to-FB followed by copy to texture (emphasis added):
Oh, sure, if the hardware doesn’t allow for RTT directly, they could make it work by other means. But, as has been pointed out, what good is that? It’s going to force driver developers to take up quite a bit of time just to have this extension support old (some might say ancient) hardware. In terms of a cost vs. reward analysis, this is prohibitive.
It’s going to force driver developers to take up quite a bit of time just to have this extension support old (some might say ancient) hardware.
If gfx hardware, with 1/8:th of a gigabyte of RAM, manufactured and sold within the last 12 months is considered “ancient” (I’m not thinking of the TNT1 or 2, which even I consider quite old), I guess I’m getting too old for this.
I think vendors indeed should expose software interfaces for the features the h/w supports. In fact, I expect them to - especially when they don’t provide neither complete documentation for the hardware nor source code for the drivers, so customers were at least given a fighting chance to themselves fix vendor errors and omissions.
I find it even more important when such vendors are members of the ARB.
But I’d like a word from someone at ATI on this. Assuming RV280 (or the whole R200 family) supports more of OpenGL (partially or fully) in h/w than ATI’s own binary-only (Win32) ICD’s expose, such as FBO, an assumption seemingly verified by the free software MESA3D+DRI implementation - thanks for the pointer PkK, is ATI going to update OpenGL support for these chips still sold by ATI Certified Partners? If not, why?
It seems I was a bit to fast when claiming that the DRI drivers support FBO. There have been changes regarding FBO and renderbuffers in the code, but at least on i915 it’s not in the extension string yet (my Radeon 9000 Pro is in another computer, I can’t try it there now).
