Direct Rendering Infrastructure

Philipp Klaus Krause wrote:
> I hvae removed GL_EXT_cull_vertex from my patch, since Brian wants to
> remove it from Mesa, too.
> 
> Since the r128 doesn't have hardware tcl all interesting features of
> Mesa's software tcl should be exposed.
> 
> This patch adds support for
> GL_ARB_vertex_buffer_object,
> GL_ARB_vertex_program,
> GL_EXT_multi_draw_arrays,
> GL_MESA_pack_invert,

What is the point of advertising GL_MESA_pack_invert if it's not 
implemented ?

Stephane

Stephane Marchesin schrieb:

> 
> What is the point of advertising GL_MESA_pack_invert if it's not
> implemented ?
> 
> Stephane
> 

According to extensions specification this extension's main purpose
seems to be making application developers life a little bit easier, just
like GL_MESA_window_pos/GL_ARB_window_pos does, not exposing hardware
features. So I thought it might be useful to advertize this one.
The i915 driver does the same.

Philipp

Philipp Klaus Krause wrote:
> Stephane Marchesin schrieb:
> 
> 
>>What is the point of advertising GL_MESA_pack_invert if it's not
>>implemented ?
>>
>>Stephane
>>
> 
> 
> According to extensions specification this extension's main purpose
> seems to be making application developers life a little bit easier, just
> like GL_MESA_window_pos/GL_ARB_window_pos does, not exposing hardware
> features. So I thought it might be useful to advertize this one.
> The i915 driver does the same.

No, the intel driver implements it.

Stephane

Philipp Klaus Krause wrote:
> Stephane Marchesin schrieb:
> 
> 
>>What is the point of advertising GL_MESA_pack_invert if it's not
>>implemented ?
>>
>>Stephane
>>
> 
> 
> According to extensions specification this extension's main purpose
> seems to be making application developers life a little bit easier, just
> like GL_MESA_window_pos/GL_ARB_window_pos does, not exposing hardware
> features. So I thought it might be useful to advertize this one.
> The i915 driver does the same.

The intel driver actually uses it however - if you set that PACK_INVERT 
parameter the driver will do optimized pixel reads (i.e. direct blits).
I don't see much point in advertizing vendor-speficic extensions if the 
hardware doesn't support it natively (that's not to say the r128 
wouldn't support GL_MESA_pack_invert in hardware, but you'd need to 
implement optimized pixel readback functions to take advantage of it).
In that sense, I'd consider NV_vertex_program as bloat just as well. 
Applications really always can deal with not available non-standard 
extensions very well.
There's some point for adding the ARB (and EXT) extensions, though 
actually ARB_vertex_program doesn't come for free. Vertex programs are 
slow currently, so if an app would use a fixed-function fallback it 
would likely be faster. Though of course not everything possible with 
ARB_vertex_program can be done with fixed function... (and in theory 
vertex programs could be just as fast as fixed function when done in 
software, it's just currently not the case with mesa).

Roland

> In that sense, I'd consider NV_vertex_program as bloat just as well.
> Applications really always can deal with not available non-standard
> extensions very well.

About GL_NV_vertex_program:
1) It was the first nice vertex program interface and is used in many
old tutorials on vertex shading.
2) Currently Mesa layers GL_ARB_vertex_program on top of
GL_NV_vertex_program. A driver that already advertizes
GL_ARB_vertex_program can support GL_NV_vertex_program for free.
3) It is a widespread extension, not a Nvidia-specific one: It is
implemented by the i915 driver, the mga driver, the tdfx driver, the
r300 driver, the non-free 3Dlabs drivers and
of course all the Nvidia drivers.
4) I added an option to deactivate it.

Philipp

Philipp Klaus Krause wrote:
>>In that sense, I'd consider NV_vertex_program as bloat just as well.
>>Applications really always can deal with not available non-standard
>>extensions very well.
> 
> 
> About GL_NV_vertex_program:
> 1) It was the first nice vertex program interface and is used in many
> old tutorials on vertex shading.
> 2) Currently Mesa layers GL_ARB_vertex_program on top of
> GL_NV_vertex_program. A driver that already advertizes
> GL_ARB_vertex_program can support GL_NV_vertex_program for free.
Sure, but I hate unneeded driver complexity, even if it's just a single 
line, so it's not completely free :-).

> 3) It is a widespread extension, not a Nvidia-specific one: It is
> implemented by the i915 driver, the mga driver, the tdfx driver, the
> r300 driver, the non-free 3Dlabs drivers and
> of course all the Nvidia drivers.
It's not completely limited to nvidia hardware, but it's still a 
non-standard extension. If you look at commercial drivers 
(www.delphi3d.net), support is indeed pretty much limited to nvidia 
hardware, the only other company to support it is 3dlabs - no ATI, no 
intel, no matrox, nothing. That is quite nvidia-specific if you ask me.

> 4) I added an option to deactivate it.
Makes the driver even more complex :-).

btw it looks you can't announce ARB_vertex_program on r128. The 
extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3. 
Not sure why exactly, there doesn't seem to be anything in the new 
features of OpenGL 1.3 which seems to be related to vertices (safe maybe 
multitexturing, or maybe matrix transpose, I didn't study the extension 
to see if you could do it with 1.2 + multitexture). NV_vertex_program 
requires only 1.2.1 though.

Roland

Roland Scheidegger schrieb:

> 
> btw it looks you can't announce ARB_vertex_program on r128. The
> extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3.

I think that leaves two options

1) Don't add any vertex program stuff to the r128 driver. In that case
the patch I posted should be ignored. Vertex program support should be
removed from the mga and tdfx drivers, since they only support OpenGL 1.2.

2) Make GL_ARB_vertex_program support a configuration option that
defaults to off. The same should be done with the mga  and tdfx drivers.

Philipp

Since vertex program support was the main point of the patch,
and the discussion has shown reasons not to add any vertex program
support to the r128 I think that my patch should be ignored.
I might create another one once Mesa implements vertex shaders.

Philipp

Philipp Klaus Krause wrote:
> Since vertex program support was the main point of the patch, and the
> discussion has shown reasons not to add any vertex program support to
> the r128 I think that my patch should be ignored. I might create
> another one once Mesa implements vertex shaders.
Well the discussion only inovlved two people :-). It's quite possible
others might think it's worthwile, I'm certainly no authority on that.
OTOH, I think EXT_multi_draw_arrays and ARB_vertex_buffer_object are 
quite reasonable to add.

Roland

Roland Scheidegger schrieb:

> 
> Well the discussion only inovlved two people :-). It's quite possible
> others might think it's worthwile, I'm certainly no authority on that.

I know. This is what Ian wrote last time I posted the patch (when it
still included GL_EXT_vertex_cull):
> My only other comment is that *all* the open-source drivers should
> support *all* of these extensions and GL_SGIS_generate_mipmap.  There
> are a few that even still need "fake" support for GL_ARB_multisample and
> GL_ARB_texture_compression added.  :( 

But since the GL_ARB_vertex_program spec says that it requires 1.3
(which the r128 can't do in hardware due to the lack of cube maps, dot3
bumpmapping and texture combining) that one can't be added (making it a
configuration option disabled by default probably isn't worth it unless
are users complaining about a missing feature).
That would only leave GL_NV_vertex_program. Since this only requires
OpenGL 1.2.1 it might become a kind of standard for vertex programs on
free linux drivers. But apart from that it would need an application
that requires it to justify it's addition. Most games probably don't
count here since they would require a faster graphics chip to be
playable anyway. Celestia might be a candidate for this. It can use
GL_NV_vertex_program and there seem to be some people using it on old
cards (even mach64).

Philipp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland Scheidegger wrote:
> Philipp Klaus Krause wrote:
> 
>> 3) It is a widespread extension, not a Nvidia-specific one: It is
>> implemented by the i915 driver, the mga driver, the tdfx driver, the
>> r300 driver, the non-free 3Dlabs drivers and
>> of course all the Nvidia drivers.
> 
> It's not completely limited to nvidia hardware, but it's still a
> non-standard extension. If you look at commercial drivers
> (www.delphi3d.net), support is indeed pretty much limited to nvidia
> hardware, the only other company to support it is 3dlabs - no ATI, no
> intel, no matrox, nothing. That is quite nvidia-specific if you ask me.

For all practical purposes, NV_vertex_program is dead.  The only
non-open-source drivers on *any* platform that support it *today* are
Nvidia's.  3dlabs used to support it, but I believe they dropped support
for it as soon as GLSL became available.  Modern Nvidia vertex program
extensions (e.g., GL_NV_vertex_program3) are layered on the ARB
extension instead of the old NV extension.

>> 4) I added an option to deactivate it.
> 
> Makes the driver even more complex :-).
> 
> btw it looks you can't announce ARB_vertex_program on r128. The
> extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3.
> Not sure why exactly, there doesn't seem to be anything in the new
> features of OpenGL 1.3 which seems to be related to vertices (safe maybe
> multitexturing, or maybe matrix transpose, I didn't study the extension
> to see if you could do it with 1.2 + multitexture). NV_vertex_program
> requires only 1.2.1 though.

I looked into this a bit.  I don't see *anything* in the ARB_vp spec
that requires OpenGL 1.3.  I can't see any reason to not expose it even
on lesser hardware.

Here's my opinion on the matter, but I'd like to hear from Brian or Keith.

1. All drivers should expose GL_ARB_vertex_program and
GL_MESA_program_debug.  I don't care either way about the NV extensions.

2. There should be a single option to disable all software vertex
program extensions.

3. If vertex programs are too slow to be usable (and they are), we
should fix that.

4. We should work towards getting GL_NV_vertex_program2_option and
GL_NV_vertex_program3 supported.  That should give us all the low-level
infrastructure that we need to support GLSL vertex shaders.

Items #1 and #2 could be handled for all drivers by a routine in
src/mesa/drivers/dri/common/utils.c.  Something like
driEnableVertexProgramExtensions(GLcontext *ctx, driOptionCache
*options) should do the trick.

Looking into my OpenGL crystal ball, my guess is that the next major
version of OpenGL (i.e., 3.0) will take the same route as OpenGL ES 2.0:
 all fixed function paths will be eliminated.  I, for one, am tired of
carrying around the dead weight of optimized fixed function paths.  I
would be tickled pink to have fixed function state tracking pulled into
a layered library that sliently generates GLSL programs for the application.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDSpqNX1gOwKyEAw8RAhpVAKCRU4+Jyo3iPelkgRUlyoZBfjr7TgCffLlI
VXp8qXoCR+s33YhI/XJ8sNo=
=BG9w
-----END PGP SIGNATURE-----

Ian Romanick schrieb:

> 
> Here's my opinion on the matter, but I'd like to hear from Brian or Keith.
> 
> 1. All drivers should expose GL_ARB_vertex_program and
> GL_MESA_program_debug.  I don't care either way about the NV extensions.

So you think we should announce it even though the spec says OpenGL 1.3
and 1.4 are required? Maybe Brian can tell us why he thinks that
GL_MESA_program_debug needs 1.4.

Philipp

Philipp Klaus Krause wrote:
> Ian Romanick schrieb:
> 
> 
>>Here's my opinion on the matter, but I'd like to hear from Brian or Keith.
>>
>>1. All drivers should expose GL_ARB_vertex_program and
>>GL_MESA_program_debug.  I don't care either way about the NV extensions.
> 
> 
> So you think we should announce it even though the spec says OpenGL 1.3
> and 1.4 are required? Maybe Brian can tell us why he thinks that
> GL_MESA_program_debug needs 1.4.

Mostly that just comes from re-using boilerplate from other extension 
specs.

If you want to be pedantic though, fragment programs have an 
instruction for biasing the mipmap levels used for texture filtering 
which has some interaction with GL_TEXTURE_LOD_BIAS, which was added 
in OpenGL 1.4.

That said, the vertex program extensions can probably be used just 
fine with OpenGL 1.2 (or perhaps older).

-Brian

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Roland Scheidegger wrote:
> 
>>Philipp Klaus Krause wrote:
>>
>>
>>>3) It is a widespread extension, not a Nvidia-specific one: It is
>>>implemented by the i915 driver, the mga driver, the tdfx driver, the
>>>r300 driver, the non-free 3Dlabs drivers and
>>>of course all the Nvidia drivers.
>>
>>It's not completely limited to nvidia hardware, but it's still a
>>non-standard extension. If you look at commercial drivers
>>(www.delphi3d.net), support is indeed pretty much limited to nvidia
>>hardware, the only other company to support it is 3dlabs - no ATI, no
>>intel, no matrox, nothing. That is quite nvidia-specific if you ask me.
> 
> 
> For all practical purposes, NV_vertex_program is dead.  The only
> non-open-source drivers on *any* platform that support it *today* are
> Nvidia's.  3dlabs used to support it, but I believe they dropped support
> for it as soon as GLSL became available.  Modern Nvidia vertex program
> extensions (e.g., GL_NV_vertex_program3) are layered on the ARB
> extension instead of the old NV extension.
> 
> 
>>>4) I added an option to deactivate it.
>>
>>Makes the driver even more complex :-).
>>
>>btw it looks you can't announce ARB_vertex_program on r128. The
>>extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3.
>>Not sure why exactly, there doesn't seem to be anything in the new
>>features of OpenGL 1.3 which seems to be related to vertices (safe maybe
>>multitexturing, or maybe matrix transpose, I didn't study the extension
>>to see if you could do it with 1.2 + multitexture). NV_vertex_program
>>requires only 1.2.1 though.
> 
> 
> I looked into this a bit.  I don't see *anything* in the ARB_vp spec
> that requires OpenGL 1.3.  I can't see any reason to not expose it even
> on lesser hardware.
> 
> Here's my opinion on the matter, but I'd like to hear from Brian or Keith.
> 
> 1. All drivers should expose GL_ARB_vertex_program and
> GL_MESA_program_debug.  I don't care either way about the NV extensions.
> 
> 2. There should be a single option to disable all software vertex
> program extensions.
> 
> 3. If vertex programs are too slow to be usable (and they are), we
> should fix that.
> 
> 4. We should work towards getting GL_NV_vertex_program2_option and
> GL_NV_vertex_program3 supported.  That should give us all the low-level
> infrastructure that we need to support GLSL vertex shaders.
> 
> Items #1 and #2 could be handled for all drivers by a routine in
> src/mesa/drivers/dri/common/utils.c.  Something like
> driEnableVertexProgramExtensions(GLcontext *ctx, driOptionCache
> *options) should do the trick.
> 
> Looking into my OpenGL crystal ball, my guess is that the next major
> version of OpenGL (i.e., 3.0) will take the same route as OpenGL ES 2.0:
>  all fixed function paths will be eliminated.  I, for one, am tired of
> carrying around the dead weight of optimized fixed function paths.  I
> would be tickled pink to have fixed function state tracking pulled into
> a layered library that sliently generates GLSL programs for the application.


I don't have any problems with any of that.

-Brian

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Paul wrote:
> Philipp Klaus Krause wrote:
>> Ian Romanick schrieb:
>>
>>> Here's my opinion on the matter, but I'd like to hear from Brian or
>>> Keith.
>>>
>>> 1. All drivers should expose GL_ARB_vertex_program and
>>> GL_MESA_program_debug.  I don't care either way about the NV extensions.
>>
>> So you think we should announce it even though the spec says OpenGL 1.3
>> and 1.4 are required? Maybe Brian can tell us why he thinks that
>> GL_MESA_program_debug needs 1.4.
> 
> Mostly that just comes from re-using boilerplate from other extension
> specs.
> 
> If you want to be pedantic though, fragment programs have an instruction
> for biasing the mipmap levels used for texture filtering which has some
> interaction with GL_TEXTURE_LOD_BIAS, which was added in OpenGL 1.4.

There's a lot of stuff in ARB_fragment_program that relies on features
in OpenGL 1.3 + extensions.  My guess is that, since ARB_vp and ARB_fp
were conceived together, the same language was just copied for both.

> That said, the vertex program extensions can probably be used just fine
> with OpenGL 1.2 (or perhaps older).

That was my conclusion as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDSrUkX1gOwKyEAw8RAgz7AJ9X51eM5P+5+WZVkfGwxaQ7pYT1FACgiQG1
oxR8nzwCfwEhRsL7+6R+8VU=
=aAt4
-----END PGP SIGNATURE-----