Questions about X1950XT (R580) opengl extensions
Hi there! it's my first thread in this forum, so here it goes
It is known that OSS radeon driver devs are working on GLSL and opengl 2.0 support for this hardware (R300-R500). Recently I found THIS page on the net, listing the opengl extensions available with the catalyst 8.6 drivers (windows) for R580. It is surprising to see that the hardware (X1950XTX in this case) supports many opengl 3.0 extensions too excluding the GL 2.1 extension GL_ARB_texture_non_power_of_two. But many important 3.0 extensions like: GL_EXT_framebuffer_object.
The question is: Will those extensions be added when the opengl 2.0 support in mesa drivers be implemented? Also the hardware seems to be supporting GLSL rev. 1.20. Will it be implemented too? Thanks!
I got my own report from OpenGL Extensions Viewer in windows using the latest (9.3) catalyst drivers:
Here in the report I can see NPOT textures, I know that the hardware doesn't support them all but will it be implemented in the mesa stack too?
Renderer: Radeon X1950 Series
Vendor: ATI Technologies Inc.
Memory: 256 MB
Version: 2.1.8543 Release
Shading language version: 1.20
Max texture size: 4096 x 4096
Max texture coordinates: 8
Max vertex texture image units: 0
Max texture image units: 16
Max geometry texture units: 0
Max anisotropic filtering value: 16
Max number of light sources: 8
Max viewport size: 4096 x 4096
Max uniform vertex components: 512
Max uniform fragment components: 512
Max geometry uniform components: 0
Max varying floats: 44
Max samples: 6
Max draw buffers: 4
v1.1 (100 % - 7/7)
v1.2 (100 % - 8/8)
v1.3 (100 % - 9/9)
v1.4 (100 % - 15/15)
v1.5 (100 % - 3/3)
v2.0 (100 % - 10/10)
v2.1 (100 % - 3/3)
v3.0 (39 % - 9/23)
v3.1 (12 % - 1/8)
v3.2 (0 % - 0/9)
Last edited by barbarbaron; 11-08-2009 at 12:36 PM.
Our current understanding is that the hardware doesn't support NPOT under certain conditions (mipmapping etc.) but does support NPOT for the more common use cases.
Unfortunately OpenGL extensions tend to get defined *after* the corresponding hardware is developed so they don't always align with hardware capabilities. DX standards tend to get defined earlier so that hardware vendors can design new hardware to match the standards.
Last edited by bridgman; 11-09-2009 at 10:34 AM.
Thanks bridgman. I have tested the framebuffer object with OpenGL Extensions Viewer and it seems not to fall to software renderer. Which makes me think it is indeed supported by hardware. Can you please answer the questions in the first post too?
Last edited by barbarbaron; 11-09-2009 at 10:55 AM.
framebuffer objects do not require any special hardware, only a decent memory manager.
The question in your first post is essentially "what is the community, which you don't manage, going to do in the future ?", so understand that this is more of a guess than a hard answer
Some OpenGL features are tied directly to implementation details of the graphics hardware, and that's where you see a tight relationship between GPU vendor/model and the degree of support. Other features are more general, in the sense that they are capabilities of the driver framework more than the hardware itself. A lot of these features were optional in GL 2.0 and simply became core requirements in 3.x.
I expect that most of the second class of features will get implemented in the open source drivers. Many of those features are/were blocked on the availability of a good common memory manager shared between X, kernel and 3D drivers, which was recently implemented and is in the process of becoming mainstream.
Tags for this Thread