it seems GeForce Fx series dont support OpenGL 2.0

[engall]

OpenGL 2.0 spec call for Multiple render targets.

But I remember that NV3x miss this feature.

So it seems GeForce Fx series dont support OpenGL 2.0.

Am I right?

And ATi all Dx9 chips support Multiple render targets.

It is much possbile that R9500 and up will meet OpenGL 2.0 requirements.

What do you think of ?

 

[Cat]

I think ARB_texture_non_power_of_two is also required for compliance, and I don't think even the X800 line supports this.

 

[Xmas]

An OpenGL implementation does not guarantee that all features provided are hardware-accelerated.

 

[Rys]

Doesn't NV3x support MRTs, just with a subset of render target formats compared to what's available in full DX9.0 ATI hardware?

Rys

 

[Evildeus]

Yeah, AFAIR.

 

[arjan de lumens]

Is there any GPU out there that can accelerate ALL of OpenGL2.0 in hardware? I was under the impression that no current GPU had the complete necessary feature set yet.

Some issues that may force GL2.0 drivers into software mode, even on recent GPUs (such as NV40 and X800), are:

• GLSL doesn't permit any limits on program length or the number of temporary variables/registers present in a shader. All GPUs that I know about impose hard hardware limits on these parameters, so that if you come with a too long or complex shader, you are forced into software rendering
• There are a number of GLSL features that do not have any counterpart in DX9 SM3.0, such as noise textures, atan, while-loops, and a whole lot of array manipulation tricks (e.g. addressable texture sampler arrays, writable arrays of temporaries) - how well are these supported in current hardware? (I suspect not at all)

But, as noted, the OpenGL standard has never dictated that its feature set is to be 100% implemented in hardware, so you can in principle write OpenGL 2.0 drivers for any GPU, implementing in software the features and feature combinations that the underlying GPU hardware doesn't support. (so that it is theoretically possible, but not terribly useful, to write an OpenGL2.0 driver for e.g. a Voodoo2)

 

[Reverend]

Er, I don't think NVIDIA claimed the GFFX supports "OpenGL 2.0".

 

[KimB]

Doesn't NV3x support MRTs, just with a subset of render target formats compared to what's available in full DX9.0 ATI hardware?

Rys

Sort of. In some ways, it's more flexible.

Basically, with ATI's hardware, you can render to multiple buffers of the same format. Often one or more of these buffers is meant to be used as a texture in the next pass of rendering.

With nVidia's NV3x hardware, you have a ceiling of 128 bits of data to output from each pixel pipeline, and can pack data into this 128 bits however you desire. One limitation is that you can't use this for render to texture, which imposes stringent limitations upon the ways you can read the buffer in on the next stage of rendering, the other that you can't output very many floating point values, but performance can be optimized by only using floating point for values where it's needed.

 

[Richteralan]

The new version of OpenGL Extension Viewer is released.
and it contains a database which shows the extensions supported each display chip.

So far my FX5600 only support 50% OpenGL 2.0 extensions.

 

[Scali]

Basically, with ATI's hardware, you can render to multiple buffers of the same format. Often one or more of these buffers is meant to be used as a texture in the next pass of rendering.

This is not entirely true. You have to use buffers of the same size (width, height and bitdepth). But you can eg use buffers of G16R16F alongside A8R8G8B8 buffers.

NVIDIA has multiple element targets instead. I would say that these are less flexible, particularly since they can't be used as a texture in subsequent passes easily.

 

[Humus]

The new version of OpenGL Extension Viewer is released.

.. and is still as misleading as previous versions.

 

[AlNom]

In what way?

Places for improvement?

 

[Richteralan]

The new version of OpenGL Extension Viewer is released.

.. and is still as misleading as previous versions.

eh....ok....
where's misleading? in which way?

 

[Ostsol]

Well, from the OpenGL 1.4 part of it. . .

OpenGL 1.4 features :

GL_EXT_generate_mipmap or GL_SGIS_generate_mipmap (automatic Mipmap generation)
GL_ARB_imaging or GL_SGI_color_matrix (adds a 4x4 matrix stack to the pixel transfer path)
GL_NV_blend_square (provides four additional blending factors)
GL_ARB_shadow or GL_SGIX_shadow or GL_EXT_shadow
GL_ARB_fog_coord or GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_secondary_color
GL_ARB_point_parameters or GL_EXT_point_parameters
GL_EXT_blend_func_separate
GL_EXT_stencil_wrap
GL_ARB_texture_env_crossbar or GL_NV_texture_env_combine4
GL_EXT_texture_lod_bias
GL_ARB_texture_mirrored_repeat or GL_IBM_texture_mirrored_repeat
GL_WIN_swap_hint or GL_IBM_rasterpos_clip
GL_ARB_vertex_program

The problem areas in this area are bolded.

First of all, all of the "or"s are untrue. If the spec mentions a specific name for an extension, the drivers had better expose that name. Even if the two versions are exactly the same (save for the names), the one in the spec has to be in the drivers. There is no "or". If a developer looks for extension strings, the right one had better be there if it is supported in hardware.

Next, there is no GL_ARB_fog_coord. I have no idea where they got that one from. . .

"GL_WIN_swap_hint or GL_IBM_rasterpos_clip". . . Actually, the extension is GL_ARB_window_pos.

GL_ARB_vertex_program. Nope. You will probably never find a video card that supports the rest of OpenGL 1.4 without it, but it's still not in the spec. There is in fact no spec that requires either GL_ARB_vertex_program or GL_ARB_fragment_program.

 

[Rolf N]

In what way?

Places for improvement?

First of all, Ostsol is right in all respects.
Second, there is no required correlation whatsoever between GL versions and extension strings. The GL version is returned by the driver when queried for the GL_VERSION string. Period. Thus the whole presumption of this program is wrong, and it wouldn't even help if the "extensions that went into the core" data would be fixed. It just doesn't make sense at all. If a driver advertises GL1.5, it is GL1.5. No matter what.

It is good practice for driver developers to keep hardware accelerated features exposed through the extension string in some way regardless of version, but there may be gaps. Witness GL_EXT_texture_3D on a Geforce 2MX. And there are good reasons for that kind of thing.

If the authors of this caps viewer don't understand this, I can't help it either. It just gives me the feeling that they actually never did any serious OpenGL development. If they were experienced OpenGL users, they wouldn't write something as horribly wrong as this.

 

[Xmas]

First of all, all of the "or"s are untrue. If the spec mentions a specific name for an extension, the drivers had better expose that name. Even if the two versions are exactly the same (save for the names), the one in the spec has to be in the drivers. There is no "or". If a developer looks for extension strings, the right one had better be there if it is supported in hardware.

It should be noted, too, that providing all those extensions is not enough for core spec compliance. Providing those extensions for backwards compatibility is a recommendation, not a requirement. Core is core, and extension is extension.

GL_ARB_vertex_program. Nope. You will probably never find a video card that supports the rest of OpenGL 1.4 without it, but it's still not in the spec. There is in fact no spec that requires either GL_ARB_vertex_program or GL_ARB_fragment_program.

The spec is a bit misleading here.

In addition to numerous additions to the classical fixed-function GL pipeline
in OpenGL 1.4, the OpenGL ARB also approved the ARB vertex program extension,
which supports programmable vertex processing.

But it is really not required.

 

[Socos]

Er, I don't think NVIDIA claimed the GFFX supports "OpenGL 2.0".

No but they did say it was DX9, and based on Valves assessment that doesn't seem to be the case at least for the 5800, 5900, & 5950.

Thats not to say it cannot run it, I guess Valve is just saying the performance is bad in HL2.

 

[Ruined]

This is on GeForce 6800GT 61.77 drivers

OpenGL 2.0 extensions (13/16) 81%

Supported:
GL_ARB_fragment_shader
GL_ARB_shader objects
GL_ARB_shading_language_100
GL_ARB_vertex_shader
WGL_ATI_pixel_format_float
GL_ATI_texture_float
GL_ARB_point_sprite
GL_ARB_texture_non_power_of_two
GL_EXT_blend_equation_seperate
GL_EXT_blend_func_seperate
GL_SUN_slice_accum
GL_ATI_draw_buffers
GL_EXT_stencil_two_side

Unsupported:
GL_ARB_half_float_pixel
GL_ARB_color_clamp_control
GL_ARB_extension_query