PDA

View Full Version : OpenGL extension rumor



yooyo
11-07-2006, 06:28 AM
New extensions are coming, but there is no any documentation about it. Maybe we need a new GL ext rumor forum. :)
This extensions was dumped from nvoglnt.dll (96.89). I suppose it expose DX10 features, but since we know all about DX10 it will be nice to know how OpenGL expose this features.

GL_ES
GL_EXTX_framebuffer_mixed_formats
GL_EXT_Cg_shader
GL_EXT_bindable_uniform
GL_EXT_depth_buffer_float
GL_EXT_draw_buffers2
GL_EXT_draw_instanced
GL_EXT_framebuffer_sRGB
GL_EXT_geometry_shader4
GL_EXT_gpu_program_parameters
GL_EXT_gpu_shader4
GL_EXT_packed_float
GL_EXT_shadow_funcs
GL_EXT_texture_array
GL_EXT_texture_buffer_object
GL_EXT_texture_compression_latc
GL_EXT_texture_compression_s3tc
GL_EXT_texture_integer
GL_EXT_texture_sRGB
GL_EXT_texture_shared_exponent
GL_EXT_transform_feedback
GL_EXT_ycbcr_422
GL_NVX_conditional_render
GL_NV_depth_buffer_float
GL_NV_framebuffer_multisample_ex
GL_NV_geometry_shader4
GL_NV_gpu_program4
GL_NV_gpu_shader4
GL_NV_parameter_buffer_object
GL_NV_texture_compression_latc
GL_NV_texture_compression_vtc
GL_NV_transform_feedback
GL_OES_conditional_query
WGL_EXT_framebuffer_sRGB
WGL_EXT_pixel_format_packed_float
WGL_NV_gpu_affinity

Gong
11-07-2006, 06:55 AM
I think it's the only way to use these new features without Vista.

Zengar
11-07-2006, 10:35 AM
That are plenty of new extensions... well, let's wait for the specs!

Korval
11-07-2006, 10:57 AM
I hope these extensions are:

1: Implemented by ATi (well, except the NV extensions of course).
2: Stopgaps until we get GL 3.0/new object API.

And isn't texture compression S3TC already there?

Texture_buffer_object sounds hawt, though.


GL_EXT_geometry_shader4Why geometry_shader4? Did we miss 1-3?

yooyo
11-07-2006, 02:13 PM
My thoughts...

GL_EXTX_framebuffer_mixed_formats
Allow to bind framebuffers with different pixelformat

GL_EXT_depth_buffer_float
Support for 32bit float depthbuffer w/o clipping 0..1

GL_EXT_draw_buffers2
Support MRT with different pixelformat. Old MRT require targets with equal number of bits. New one remove this restriction

GL_EXT_draw_instanced
Geometry instancing

GL_EXT_framebuffer_sRGB
Support for sRGB framebuffer. I think that this extension is already documented in registry

GL_EXT_geometry_shader4
Geometry shader (in GLSL)

GL_EXT_gpu_program_parameters
Not new... http://www.opengl.org/registry/specs/EXT/gpu_program_parameters.txt

GL_EXT_gpu_shader4
Allow to allocate shader units for gemetry, vertex or fragment processing

GL_EXT_packed_float
New float texture formats (R9G9B9E5 or R11G11B10)

GL_EXT_texture_array
Array of textures. Allow to bind array to sampler.

GL_EXT_texture_buffer_object
Allow direct access to texture memory

GL_EXT_texture_compression_latc
Luminance+alpha compression

GL_EXT_texture_integer
Integer textures.

GL_EXT_texture_sRGB
http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_sRGB.txt

GL_EXT_texture_shared_exponent
related to float texture R9G9B9E5_SHAREDEXP

GL_EXT_transform_feedback
I just don't know :(

GL_EXT_ycbcr_422
Seen this before... YUV texture format? Quadro only?

GL_NVX_conditional_render
Related to occlusion query.

GL_NV_depth_buffer_float
Same as EXT version but with some NVidia specific stuff, or... it is NVidia extension promoted to EXT

GL_NV_framebuffer_multisample_ex
Programmabile framebuffer multisampling

GL_NV_geometry_shader4
Just like EXT version

GL_NV_gpu_program4
Just like EXT version

GL_NV_gpu_shader4
Just like EXT version.. related to allocating shader units for vertex, geometry or fragment processing

GL_NV_parameter_buffer_object
Allow to bind any buffer as shader program parametar

GL_NV_texture_compression_latc
Just like EXT version

GL_NV_texture_compression_vtc
http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_compression_vtc.txt

GL_NV_transform_feedback
I have no idea!!!

GL_OES_conditional_query
I have no idea!!!

WGL_EXT_framebuffer_sRGB
offscreen sRGB render target

WGL_EXT_pixel_format_packed_float
allow packed float backbuffer or pbuffer?

WGL_NV_gpu_affinity
Fine grained SLI control?

mnemonicj
11-07-2006, 02:31 PM
Hi!

I've tried to sort gl extensions procedures (obtained from that drivers as well).
Here's what I found...

GL_EXT_transform_feedback
glActiveVaryingEXT
glGetActiveVaryingEXT
glBindFragDataLocationEXT
glGetFragDataLocationEXT
glTransformFeedbackAttribsEXT
glTransformFeedbackVaryingsEXT
glBeginTransformFeedbackEXT
glEndTransformFeedbackEXT

GL_NV_transform_feedback
glActiveVaryingNV
glGetActiveVaryingNV
glBindFragDataLocationNV
glGetFragDataLocationNV
glTransformFeedbackAttribsNV
glTransformFeedbackVaryingsNV
glBeginTransformFeedbackNV
glEndTransformFeedbackNV

GL_EXT_draw_instanced
glDrawArraysInstancedEXT
glDrawElementsInstancedEXT
?glDrawMesh
?glDrawMeshNV

GL_NVX_conditional_render
glBeginConditionalRenderNVX
glEndConditionalRenderNVX

GL_OES_conditional_query
glBeginConditionalRenderOES
glEndConditionalRenderOES

GL_EXT_texture_array
glGenArraySetsARB
glDeleteArraySetsARB
glBindArraySetARB
glIsArraySetARB

GL_EXT_texture_buffer_object
glTexBufferEXT

GL_EXT_bindable_uniform
glBindBufferBaseEXT
glBindBufferOffsetEXT
glBindBufferRangeEXT
glGetUniformOffsetEXT
glGetUniformBufferSizeEXT
glGetUniformuivEXT

GL_NV_parameter_buffer_object
glBindBufferBaseNV
glBindBufferOffsetNV
glBindBufferRangeNV
glGetUniformBufferSizeNV
glGetUniformuivNV

glGetProgramEnvParameterIivNV
glGetProgramEnvParameterIuivNV
glGetProgramLocalParameterIivNV
glGetProgramLocalParameterIuivNV
glProgramBufferParametersIivNV
glProgramBufferParametersIuivNV
glProgramBufferParametersfvNV
glProgramEnvParameterI4iNV
glProgramEnvParameterI4ivNV
glProgramEnvParameterI4uiNV
glProgramEnvParameterI4uivNV
glProgramLocalParameterI4iNV
glProgramLocalParameterI4ivNV
glProgramLocalParameterI4uiNV
glProgramLocalParameterI4uivNV

GL_EXT_depth_buffer_float
glClearDepthdEXT
glDepthBoundsdEXT

GL_NV_depth_buffer_float
glClearDepthdNV
glDepthBoundsdNV

GL_EXT_texture_integer
glTexParameterIivEXT
glTexParameterIuivEXT

GL_NV_framebuffer_multisample_ex
glRenderbufferStorageMultisampleExNV


And I couldn't sort this out :

glFramebufferTextureFaceEXT
glFramebufferTextureLayerEXT

glClearColorIiEXT
glClearColorIuiEXT
glEnableIndexedEXT
glDisableIndexedEXT
glIsEnabledIndexedEXT
glColorMaskIndexedEXT
glGetBooleanIndexedvEXT
glGetIntegerIndexedvEXT


glGpuSyncAcquireNVX
glGpuSyncCopyBufferNVX
glGpuSyncEndNVX
glGpuSyncGetHandleSizeNVX
glGpuSyncInitNVX
glGpuSyncMapBufferNVX
glGpuSyncReleaseNVX
glGpuSyncUnmapBufferNVX

Gong
11-07-2006, 04:08 PM
I think GL_EXT_transform_feedback == "Stream output" in DX10

MZ
11-07-2006, 04:59 PM
How about max texture dimensions?

Gong
11-07-2006, 07:51 PM
at least 8192

Slang
11-07-2006, 08:37 PM
Are those extensions going to be implemented in ICDs for Windows XP?

zed
11-07-2006, 08:38 PM
IMO GL_ES is the most interesting
the forerunner to gl3.0 perhaps

also yes texture_buffer_object does sound good, itll make gpgpu stuff more viable

texture arrays are great (should of been there since years) the only problem is the lack of existing paint programs that deal with multiple channels (layers dont cut it)
perhaps a market for someone who gets in there quick + establishes themselves

Zengar
11-07-2006, 09:03 PM
As 8800 is out today, I guess we will get the specs pretty soon ^^

mnemonicj
11-07-2006, 10:15 PM
Are those extensions going to be implemented in ICDs for Windows XP? I've found extensions and entry points in 96.89 on my WinXP SP2. :D

BlackBox
11-08-2006, 01:33 AM
Originally posted by Zengar:
As 8800 is out today, I guess we will get the specs pretty soon ^^ Only a few hours left! It would be nice to have a timetable/indication/or hint as when new extensions will arrive for us poor developers.

Lets hope nvidia launches something soon (like they always do and I'm happy about). :)

mnemonicj
11-08-2006, 03:28 AM
I don't think that we will have extension documentation today. :(
It always takes them a few weeks unfortunately. Look at Siggraph 2006 documentation at nvidia site, you will find that Next Generation Programmability in OpenGL is "coming soon". It has been 3 months since and nothing... :(

So, I've decided to investigate drivers myself. :D

I've found that there is a Cg 1.6 inside, that is able to compile geometry shaders. There are new profiles vp50, fp50, gp4gp, gp4fp, gp4fp.

vp50 and fp50 have full integer support (bitwise operation, etc.), I presume that gp stands for Geometry Program. I think that it has something to do with GL_EXT_transform_feedback extensions.

Also, there are
TRIANGLE_OUT
TRIANGLE
TRIANGLE_ADJ
LINE
LINE_ADJ
POINT_OUT
POINT

flatAttribute
emitVertex
restartStrip

x4texCUBEARRAYfetch
x4texCUBEARRAYlod
x4texCUBEARRAYbias
x4texCUBEARRAYproj
x4texCUBEARRAY
x4tex2DARRAYfetch
x4tex2DARRAYlod
x4tex2DARRAYbias
x4tex2DARRAYproj
x4tex2DARRAY
x4tex1DARRAYfetch
x4tex1DARRAYlod
x4tex1DARRAYbias
x4tex1DARRAYproj
x4tex1DARRAY
x4texCUBEfetch
x4texCUBElod
x4texCUBEbias
x4texCUBEproj
x4texCUBE

I've found document that only briefly touches geometry shaders in Cg.
On page 40 of http://developer.download.nvidia.com/presentations/2006/siggraph/kilgard-siggraph-06.pdf

Also, there is a DirectX 10 document from Siggraph 2006 GPU Shading and Rendering Course that has information on geometry shader execution model.
http://www.csee.umbc.edu/~olano/s2006c03/ch02.pdf

Presentations from course can be found at http://www.csee.umbc.edu/~olano/s2006c03/

What to say, the future looks nice. :)

It would be much better if we can have OpenGL extension documentation a month before card releases to public, so that we can prepare for new features.

zeoverlord
11-08-2006, 07:08 AM
GL_NVX_conditional_render - looks promising, finally occlusion queries can be made useful, possibly triggering a specific rendering segment based on the outcome of previous occlusion queries without stalling the cpu or the gpu, that's good.

GL_EXT_geometry_shader4
GL_EXT_gpu_shader4
Shader model 4 goodies (i suspect that's what the 4 is for), i also guess that GL_EXT_gpu_shader4 is the old fragment and vertex shader extensions put into a single extension.

GL_EXT_draw_instanced - finally.

Exiting times indeed, i can't wait to try some of them out

3k0j
11-08-2006, 08:09 AM
Hey, wait a minute. There must be some mistake. This can't be possible.

These stuff above looks like features of DirectX 10. And, I'm sure you've heard it already, DirectX 10 will be on Microsoft Vista™ only. That's because Microsoft Vista™ comes with rewritten Kennel™ and totally new Drivel Model™. For this technical reason, it would be impossible to retrofit DirectX 10 on Windows XP. I heard it clear, many times.

Korval
11-08-2006, 08:54 AM
The problem with these extensions is that they don't actually mean anything yet. Do we even know if the ARB was consulted, or is this shades of the GeForce 3 days, when nVidia would just throw out a bunch of extensions that they expected others to implement or not at their own leisure.


texture arrays are great (should of been there since years) the only problem is the lack of existing paint programs that deal with multiple channels (layers dont cut it)
perhaps a market for someone who gets in there quick + establishes themselvesI don't know what a paint program has to do with arrays of textures. You're basically talking about a mechanism for switching between multiple textures as needed on the GPU without the overhead of an actual branch operation.


DirectX 10 will be on Microsoft Vista™ only. That's because Microsoft Vista™ comes with rewritten Kennel™ and totally new Drivel Model™The rampant anti-Microsoft nonsense is not helpful.

zeoverlord
11-08-2006, 09:34 AM
Originally posted by Korval:
The problem with these extensions is that they don't actually mean anything yet. Do we even know if the ARB was consulted, or is this shades of the GeForce 3 days, when nVidia would just throw out a bunch of extensions that they expected others to implement or not at their own leisure. If it has a EXT tag then the ARB(or whatever they call themselves today after the merger with khronos) has been involved.
The NVX is just experimental extensions like GL_NVX_instanced_arrays which has probably transformed into GL_EXT_draw_instanced.

The other NV extensions is a reflection of ATI's lagging behind on the release of their SM4 hardware.
They probably can't call it EXT because ATI cant reveal if this extension can be supported just yet since the hardware/driver is still technically under development.
IT's probably just a formality.

Zengar
11-08-2006, 09:53 AM
@sk0j:
You are talking nonsense :-/
It is totally up to Nvidia what to expose in their drivers. There will be no DirectX 10 in Xp, sure, but what does it have to do with OpenGL? I find it funny that everyone concentrates on DirectX as THE standard...

zed
11-08-2006, 10:48 AM
Originally posted by Korval:
I don't know what a paint program has to do with arrays of textures. You're basically talking about a mechanism for switching between multiple textures as needed on the GPU without the overhead of an actual branch operation.sorry my mistake, a misunderstanding on my part of what it actually does

whens the quarterly newsletter due (seems about time?)

Brolingstanz
11-08-2006, 11:14 AM
There once was a man from Trinity
Who tried to use gpu_affinity
He found that without words the affair was absurd
So he gave up CG for divinity

He tossed in the sponge for some hot tea and crumpets
Then sprang into action, to the sound of great trumpets
Boldly he tried to make sense of the spec
But with nothing to read he become a wretched wreck

"I need a spec!", he hooted, he yelped and he hounded
"Hearsay and hunches just leave me confounded!"
"Were I assuaged", he then mused in his stupor
"Accede I would not, to the foulness of rumor."

With a glint in his eye he then took to his feet
Gallantly bidding a hasty retreat
Promising henceforth, as he sailed forth to Bimini
To wait 'till tomorrow to again try gpu_affinity.

-- Anonymous

cass
11-08-2006, 01:56 PM
Originally posted by Slang:
Are those extensions going to be implemented in ICDs for Windows XP? Of course!

Zengar
11-08-2006, 02:16 PM
Cass, can you possibly say something more then "of course"? I mean, we are all nerds, we are dying from curiosity ^^

cass
11-08-2006, 03:13 PM
One of the traditional NVIDIA OpenGL Extensions docs is being readied and should be on developer.nvidia.com Real Soon Now.

We'll be following up with Cg 2.0 support for the new programmability shortly thereafter.

You think the wait is hard for you... I have been waiting for years to talk about this stuff. :)

Zengar
11-08-2006, 03:30 PM
Actually this is/was a good chance for OpenGL... Bringing the new functionality without need to use Vista...

And cass, thank you very much! Keep up the good work, it's because of people like you, Mark and Simon I always liked Nvidia! :-)

Korval
11-08-2006, 04:36 PM
One of the traditional NVIDIA OpenGL Extensions docs is being readied and should be on developer.nvidia.com Real Soon Now.Since you won't get into time specifics, I'll ask you this. Will they be there before or after the upcoming double-console launch?


You think the wait is hard for you... I have been waiting for years to talk about this stuff.Well talk about it, then! At least you won't have to keep things bottled up, and we'll know everything we want to. Don't let that whole, "violating NDA's and losing your job" thing stop you ;)


Actually this is/was a good chance for OpenGL... Bringing the new functionality without need to use Vista... Not good enough. The window of opportunity is really only about 1.5-2 years or so; gamers are pretty willing to upgrade machines, which is a perfect time to do an OS upgrade too.

The ARB really needed to get on that new API thing a year earlier. In one year's time, all of these extensions will be supplanted by the new API (or, rather, it had better be...), and nobody will care.

zed
11-08-2006, 04:48 PM
one question
how much is gonna be available without a gf8800, i mean will cg2.0 open up lots of new possibilities for me with my brand spanking new since yesterday (soon to be outdated) gf7600

btw - pc games bah not worthwhile IMO consoles is where its at, 80% market at the moment + what with the new consoles resembling pcs even more that percentage is only gonna grow

cass
11-08-2006, 06:50 PM
Thanks for the compliment, Zed. Mark, Simon, and I really care about the OpenGL developer community, and I'm glad you've noticed. ;)

Korval, I'll try to get more detailed info than "Real Soon Now". I'd rather not say more until I can say something definitive, but there's no longer any secrecy issue. I'm pretty sure we'll have the document out ASAP.

It may take reading the extension specs for you to have detailed questions, but when you do, I'll do my best to answer quickly. If I happen to not be monitoring the thread as quickly as you'd like, feel free to email me at cass@nvidia.com.

As to what Cg 2.0 will open up, it is still a layer above the underlying OpenGL or D3D abstraction. Truly new hardware functionality will be available only where the hardware supports it.

One important exception is in the addition of parameter buffer objects, though. Because GeForce 8 series supports shader parameters from buffer objects, we are going to provide this abstraction to all existing profiles. This should significantly reduce the overhead of parameter updates - and allow the app the update many parameters efficiently with a BufferSubData call.

Likewise, new object model directions with GL3 will enhance the efficiency of Cg runtime calls.

I look forward to hearing what you guys want to do with all the cool new features. It will be a learning process for us - and one that I welcome.

Gong
11-08-2006, 10:17 PM
Originally posted by cass:
As to what Cg 2.0 will open up...
One important exception is in the addition of parameter buffer objects, though. Because GeForce 8 series supports shader parameters from buffer objects, we are going to provide this abstraction to all existing profiles. This should significantly reduce the overhead of parameter updates - and allow the app the update many parameters efficiently with a BufferSubData call.
Glad to heard that!

V-man
11-08-2006, 11:23 PM
GL_EXT_texture_integer
Might be for using integer texcoords to access texels precicely

GL_NV_gpu_program4
GL_NV_gpu_shader4
Low level and high level. Not sure why the word gpu is there.

GL_EXT_geometry_shader4
****!

GL_NV_transform_feedback
At first I thought this was to transform vertices from one VBO and write to another VBO but the API looks like it's fr something else.

...well it's a long list.

Slang
11-08-2006, 11:34 PM
NVIDIA developer website has been just updated and here they come:

GeForce 8 Series (G8X) OpenGL Extensions
http://developer.download.nvidia.com/opengl/specs/g80specs.pdf

Release Notes for NVIDIA OpenGL Shading Language Support (Oct 27 2006)
http://developer.download.nvidia.com/opengl/glsl/glsl_release_notes.pdf

mnemonicj
11-08-2006, 11:43 PM
nVidia guys thank you very much !!!

Overmind
11-09-2006, 12:21 AM
I just read through the most interesting new specs, and I really like it ;)

Great work.

Can't wait to get my hands on hardware capable of actually doing all that stuff ;)

mnemonicj
11-09-2006, 02:58 AM
I've just tested NVEmulate. It works!

The only problem is that documentation says to use Release 95 driver, preferably version 97.02 or later. But 97.02 is only for GeForce 8800, and it cannot be installed on my 6800, so I've used 96.89 instead. And all extensions are there + GLSL support for geometry shaders.

nVidia guys, thanks again!

Mars_999
11-09-2006, 04:10 AM
Question for cass. With the texture array extension will one be able to do away with the texture mosaic(atlas) and use this extension so one could use filtering other than linear? I am as of now using 16 textures in a single texture atlas, but can't use tri-linear filtering due to bleeding over issues. And what gains will I see in shadows with the floating depth buffer extension? And yes I will second that Thanks a lot for the OpenGL support from you and Nvidia. That's why I keep buying NVIDIA hardware! ;)

BTW will there be any GS examples for GLSL on the nvidia developer site?

elFarto
11-09-2006, 04:59 AM
Originally posted by Mars_9999:
Question for cass. With the texture array extension will one be able to do away with the texture mosaic(atlas) and use this extension so one could use filtering other than linear?I just read through the spec for it, and it certainly seems like it can be used to replace texture atlases. It appears texture filtering only affects each layer, and not between them.


Originally posted by Mars_9999:
...Thanks a lot for the OpenGL support from you and Nvidia. That's why I keep buying NVIDIA hardware! ;) Me too, but the power consumption of their new cards is a little excessive.

Regards
elFarto

Mars_999
11-09-2006, 05:25 AM
Me too, but the power consumption of their new cards is a little excessive.


Not really, look at the reviews when under load it consumes about as much power as ATI's x1950xtx. So IMO that's not bad at all for the size of the 8800GTX.

cass
11-09-2006, 05:42 AM
Hi Mars_9999,

Yes, you should be able to use texture arrays as a better form of texture atlas, with trilinear, aniso, etc.

And our devtech group is working on demos of all the new functionality. I can't say for sure when a GLSL version of geometry programs will show up. The assembly version (compiled from Cg) will probably show up first though.

Thanks -
Cass

Mars_999
11-09-2006, 05:47 AM
This is great news cass. Just made my day. Now looks like I will need to do some magic and drop all the images into a 3D array and then upload at runtime until someone or maybe I will code a utility to pack 2D .tgas into a 3D file format for this extension. Hmmm...

Zeno
11-09-2006, 08:19 AM
First I'd like to congratulate Cass and NVIDIA on what looks to be awesome hardware. I'm especially happy about the anisotropic filtering fix and the improved support for fp16/32 blending and anti-aliasing. I should have a card and system to test things with by early next week :)

I noticed someone asked about the new max texture dimension.

I'd like to ask about the max 3D texture dimension...please say it's moved beyond 512 now?

Thanks!

Mars_999
11-09-2006, 08:26 AM
The new 2d max is 8192x8192 As for the 3d texture I thought I seen that was upped also 4096? Don't quote me. I will know by the end of day if you would like. Card is here today sometime. :)

griffin2000
11-09-2006, 08:40 AM
Awesome ! I had resigned myself to paying for the next installment of the Microsoft virus :-) Looks like I will be dusting of my ol' opengl programming manual (last time I used OGL was on a SGI box :-) ).

Though do we need a new version of the CG compiler to use this ? Will you be able to do anything without CG support (can you use hand code assembly without CGC ?).

Zengar
11-09-2006, 09:13 AM
The new Nvidia extensions include the new functionality via OpenGL shading language and via assembly programs. You already have this choice. Why would you need Cg here?

MZ
11-09-2006, 09:41 AM
I haven't read all of the specs, so I might be wrong, but the EXT_draw_instanced looks suspicious.

1. Minor typo in pseudocode: DrawArrays and DrawElements have 1 param too much, or else my GL skills are really getting rusty :)

2. This doesn't seem like D3D9 instancing.
In the D3D9 instancing you have 2 separate array data: one that changes only per instance, and the other, that changes with wrapping modulo instance. This extension only gives you the latter. I think the former array is supposed to be emulated by using the "instanceID" with vertex texture fetch.

So it's not the "holy grail", single-call instancing solution for D3D9-grade cards, as expected by some people on this forum. It's for the new hardware only.

Zengar
11-09-2006, 09:54 AM
Actually, this extension only gives you the current primitive number. IMHO, it is more convenient and flexible then DX9 instancing. Actually, Nvidia was working on a more DX9-like extension, looks like they gave it up. But as there is little need for it in OpenGL, why not?

Korval
11-09-2006, 10:21 AM
The new 2d max is 8192x8192Doesn't DX10 support have some requirement of unlimited texture resolution or something? I remember someone saying or suggesting something like that.

Not that I personally have a problem with a maximum. 4096 was plenty to me. Heck, 2048 was just dandy.

On draw_instanced:

This seems rather useless. At the very least, it's not useful for what the D3D instancing was useful for. All it does is provide the shader with an integer that specifies which number it is in the instance sequence.

Since this is G80 hardware, I suppose you could bind a gigantic uniform struct array (since it supports gigantic uniform struct arrays. Especially as buffer objects ;) ) that has all your per-instance data in it, and then you just pick an index based on the instance value.

Fine for G80 hardware. But, then again, since the extension is only supported by G80 hardware...

On NV_texture_feedback:

A reasonable extension. One question though: why is this an NV extension? D3D-10 requires this functionality. Even if ATi isn't going to be releasing a DX10 part in the immediate future, they're still going to have to provide that support.


BTW, I take it on faith that all of this stuff will be folded into the new API where appropriate/reasonable?

Lastly, I'm very thankful that nVidia now support framebuffer multisample and blitting now. Specifically on my GeForce 6600. I'm not going to be getting a G80-based card until they start coming down to mroe reasonable prices ($200 or less), so I'm glad to see some useful features popping into older cards that can handle them.

Antialiasing with FBO's is a great thing and should be enjoyed by all.

knackered
11-09-2006, 10:50 AM
I'm getting too old for this.
How's the new API going Cass?

Mars_999
11-09-2006, 11:57 AM
Ok, max 3d is 2048x2048x0248 and Cubemaps 8192x8192

Zeno
11-09-2006, 12:18 PM
Originally posted by Mars_9999:
Ok, max 3d is 2048x2048x0248 and Cubemaps 8192x8192 Great news, thanks!

Korval
11-09-2006, 02:13 PM
How's the new API going Cass?Seconded. It's been a while since our last update on GL happennings.

pbrown
11-09-2006, 04:36 PM
Originally posted by Korval:
...
On NV_texture_feedback:

A reasonable extension. One question though: why is this an NV extension? D3D-10 requires this functionality. Even if ATi isn't going to be releasing a DX10 part in the immediate future, they're still going to have to provide that support.
The following snippet in the spec history is likely relevant to your question. It wasn't possible to complete an EXT in time to get it into the first drivers of the 8800.

7 10/17/06 pbrown Rename from EXT to NV while working on
standardizing a functional subset extension
that will be named EXT_transform_feedback. We
expect that the EXT should be equivalent to
the NV, except that it (a) removes support for
non-GLSL usage, (b) removes the ability to
change the set of varyings captured without
relinking. NVIDIA expects to support both the
NV and EXT forms of this extension going
forward. Fix state table formatting. Removed
GetFloatIndexedvEXT and GetDoubleIndexedvEXT,
which are not needed by this and related
extensions.

pbrown
11-09-2006, 04:39 PM
Originally posted by Mars_9999:
The new 2d max is 8192x8192 As for the 3d texture I thought I seen that was upped also 4096? Don't quote me. I will know by the end of day if you would like. Card is here today sometime. :) The 3d texture maximum size on G80 is 2048x2048x2048. Additionally, EXT_texture_array on G80 allows for up to 512 layers of 8192x8192 images.

Korval
11-09-2006, 05:39 PM
I love this quote from the texture_array spec:


(4) Should DEPTH_COMPONENT textures be supported for texture arrays?
RESOLVED: Yes; multi-layer shadow maps are useful.O Rly? ;) Was this ever really in question?

Just the possibility of that alone makes me want to have G80 hardware...

Oh, and as for new API info, from the same spec:


We expect that future revisions of the GL will change the specification of mipmapped textures inI'd love to see that phrase completed. And in what way the new API is going to change how you access mipmaps to make this possible. I assume that would mean that texture mip levels will be treated as first-class texture objects in some way? Or, at least, be not so entirely bound to the texture to which they are attached.

BTW, it turns out I was wrong:


I don't know what a paint program has to do with arrays of textures. You're basically talking about a mechanism for switching between multiple textures as needed on the GPU without the overhead of an actual branch operation.You would "need" (not really need, but it'd be rather helpful) some form of tool support use texture arrays as a replacement for an atlas.

Mars_999
11-09-2006, 05:51 PM
Originally posted by pbrown:

Originally posted by Mars_9999:
The new 2d max is 8192x8192 As for the 3d texture I thought I seen that was upped also 4096? Don't quote me. I will know by the end of day if you would like. Card is here today sometime. :) The 3d texture maximum size on G80 is 2048x2048x2048. Additionally, EXT_texture_array on G80 allows for up to 512 layers of 8192x8192 images. Thanks but I posted a few back the update to my last statement. :)

And yes Korval it would be nice to pack them into a 3D array and save it out as some file format that has a loader that will load them for you. I am thinking about doing this myself, but I am time limited right now... But for now I am going to just dump all my 2D textures into a C++ 4D array and upload them as a 3D texture and go from there for now. Now about that float depth buffer ext...


Update: for Cass, I just checked and this ext isn't on my list

GL_EXT_geometry_shader4

but the nvidia site says it should be?

pbrown
11-09-2006, 06:41 PM
Originally posted by Mars_9999:
Update: for Cass, I just checked and this ext isn't on my list

GL_EXT_geometry_shader4

but the nvidia site says it should be? Our G80 GLSL compiler support is currently in beta form, and is not exposed by default. You can enable these extensions with the NVemulate (http://developer.nvidia.com/object/nvemulate.html) tool.

cass
11-09-2006, 06:43 PM
It is cool that 3D textures have such a crazy max size now, but consider that the texel address is 33 bits, or 8 gigatexels.

Max 2D texture is a 26 bit texel address, and in the max array size it's a 35 bit texel address, or 32 gigatexels.

That's a lot of memory to dedicate to a single texture!

Knackered and Korval, maybe I can get Barthold or Michael Gold to give a brief update on the GL3 goings on... I have particular bits I'm interested in, but they have a much better holistic view of how things are progressing.

Mars_999
11-09-2006, 06:51 PM
I guess this has to be asked and probably not going to get a definitive answer but at least reply! :) When is FX2.0 coming out? I know that at GDC a year or two ago it was beta then... And GDC06 I think they talked about GLSL support? This is all public knowledge IIRC... Because I am still forced to use Render Monkey until you ship FX2.0. Because it would be nice to do some of this in FX Composer, considering we are all GL nuts here and that includes GLSL. ;) Thanks

ymxie
11-09-2006, 08:57 PM
Dear all,


where can download nvidia "glext.h" file for GeForce 8 Series (G8X) OpenGL Extensions.

ze moo
11-09-2006, 10:43 PM
Originally posted by zeoverlord:
GL_NVX_conditional_render - looks promising, finally occlusion queries can be made useful, possibly triggering a specific rendering segment based on the outcome of previous occlusion queries without stalling the cpu or the gpu, that's good.
looks like GL_NVX_conditional_render has been in the
drivers since at least 7xx.xx

check the nvidia sdk, there's even a demo

ymxie
11-10-2006, 02:07 AM
my Geforce 8800 GTX driver: 9702 opengl extensions info:

but no :GL_NV_gpu_program4
NV_fragment_program4
GL_EXT_geometry_shader4
NV_geometry_program4
.........extensions


OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8800 GTX/PCI/SSE2
OpenGL version string: 2.1.0
OpenGL extensions (GL_):
GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_draw_buffers,
GL_ARB_fragment_program, GL_ARB_fragment_program_shadow,
GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_imaging,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite,
GL_ARB_shadow, GL_ARB_shader_objects, GL_ARB_shading_language_100,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_dot3, GL_ARB_texture_float,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader,
GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float,
GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr,
GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate,
GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_compiled_vertex_array, GL_EXT_Cg_shader, GL_EXT_depth_bounds_test,
GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_draw_range_elements,
GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample,
GL_EXT_framebuffer_object, GL_EXTX_framebuffer_mixed_formats,
GL_EXT_framebuffer_sRGB, GL_EXT_gpu_program_parameters,
GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_float,
GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters,
GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D,
GL_EXT_texture_array, GL_EXT_texture_buffer_object,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_integer, GL_EXT_texture_lod, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_sRGB,
GL_EXT_texture_shared_exponent, GL_EXT_timer_query, GL_EXT_vertex_array,
GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color,
GL_NV_depth_buffer_float, GL_NV_depth_clamp, GL_NV_fence,
GL_NV_float_buffer, GL_NV_fog_distance, GL_NV_fragment_program,
GL_NV_fragment_program_option, GL_NV_fragment_program2,
GL_NV_framebuffer_multisample_ex, GL_NV_gpu_program4, GL_NV_half_float,
GL_NV_light_max_exponent, GL_NV_multisample_filter_hint,
GL_NV_occlusion_query, GL_NV_packed_depth_stencil,
GL_NV_parameter_buffer_object, GL_NV_pixel_data_range, GL_NV_point_sprite,
GL_NV_primitive_restart, GL_NV_register_combiners,
GL_NV_register_combiners2, GL_NV_texgen_reflection,
GL_NV_texture_compression_latc, GL_NV_texture_compression_vtc,
GL_NV_texture_env_combine4, GL_NV_texture_expand_normal,
GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2,
GL_NV_texture_shader3, GL_NV_transform_feedback, GL_NV_vertex_array_range,
GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1,
GL_NV_vertex_program2, GL_NV_vertex_program2_option, GL_NV_vertex_program3,
GL_NVX_conditional_render, GL_OES_conditional_query,
GL_SGIS_generate_mipmap, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SGIX_shadow, GL_SUN_slice_accum, GL_WIN_swap_hint, WGL_EXT_swap_control.
GLU version string: 1.2.2.0 Microsoft Corporation
GLU extensions (GLU_):
GL_EXT_bgra.
WGL extensions (WGL_):
WGL_ARB_buffer_region, WGL_ARB_extensions_string, WGL_ARB_make_current_read,
WGL_ARB_multisample, WGL_ARB_pbuffer, WGL_ARB_pixel_format,
WGL_ARB_pixel_format_float, WGL_ARB_render_texture,
WGL_ATI_pixel_format_float, WGL_EXT_extensions_string,
WGL_EXT_framebuffer_sRGB, WGL_EXT_pixel_format_packed_float,
WGL_EXT_swap_control, WGL_NV_float_buffer, WGL_NV_render_depth_texture,
WGL_NV_render_texture_rectangle.
+-----+-------------------------+-----------------+----------+-----------------+----------+
| | visual | color | ax dp st | accum | layer |
| id | tp ac gd fm db sw st ms | sz r g b a | bf th cl | sz r g b a | ov un sw |
+-----+-------------------------+-----------------+----------+-----------------+----------+
| 1 | wp fu y i . . . . | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 2 | wp fu y i . . . . | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 3 | wp fu y i . . . . | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 4 | wp fu y i . . . . | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 5 | wp fu y i . . . . | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 6 | wp fu y i . . . . | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 7 | wp fu . i y x . . | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 8 | wp fu . i y x . . | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 9 | wp fu . i y x . . | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 10 | wp fu . i y x . . | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 11 | wp fu . i y x . . | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 12 | wp fu . i y x . . | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 13 | wp fu . i y c . . | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 14 | wp fu . i y c . . | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 15 | wp fu . i y c . . | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 16 | wp fu . i y c . . | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 17 | wp fu . i y c . . | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 18 | wp fu . i y c . . | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 19 | wp fu . i y x . 2 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 20 | wp fu . i y x . 2 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 21 | wp fu . i y x . 2 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 22 | wp fu . i y x . 2 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 23 | wp fu . i y x . 2 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 24 | wp fu . i y x . 2 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 25 | wp fu . i y c . 2 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 26 | wp fu . i y c . 2 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 27 | wp fu . i y c . 2 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 28 | wp fu . i y c . 2 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 29 | wp fu . i y c . 2 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 30 | wp fu . i y c . 2 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 31 | wp fu . i y x . 4 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 32 | wp fu . i y x . 4 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 33 | wp fu . i y x . 4 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 34 | wp fu . i y x . 4 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 35 | wp fu . i y x . 4 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 36 | wp fu . i y x . 4 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 37 | wp fu . i y c . 4 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 38 | wp fu . i y c . 4 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 39 | wp fu . i y c . 4 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 40 | wp fu . i y c . 4 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 41 | wp fu . i y c . 4 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 42 | wp fu . i y c . 4 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 43 | wp fu . i y x . 8 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 44 | wp fu . i y x . 8 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 45 | wp fu . i y x . 8 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 46 | wp fu . i y x . 8 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 47 | wp fu . i y x . 8 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 48 | wp fu . i y x . 8 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 49 | wp fu . i y c . 8 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 50 | wp fu . i y c . 8 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 51 | wp fu . i y c . 8 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 52 | wp fu . i y c . 8 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 53 | wp fu . i y c . 8 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 54 | wp fu . i y c . 8 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 91 | pb fu . i . . . . | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 92 | pb fu . i . . . . | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 93 | pb fu . i . . . . | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 94 | pb fu . i . . . . | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 95 | pb fu . i . . . . | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 96 | pb fu . i . . . . | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 97 | pb fu . i y x . . | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 98 | pb fu . i y x . . | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 99 | pb fu . i y x . . | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 100 | pb fu . i y x . . | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 101 | pb fu . i y x . . | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 102 | pb fu . i y x . . | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 103 | pb fu . i y c . . | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 104 | pb fu . i y c . . | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 105 | pb fu . i y c . . | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 106 | pb fu . i y c . . | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 107 | pb fu . i y c . . | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 108 | pb fu . i y c . . | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 109 | pb fu . i . . . 2 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 110 | pb fu . i . . . 2 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 111 | pb fu . i . . . 2 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 112 | pb fu . i . . . 2 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 113 | pb fu . i . . . 2 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 114 | pb fu . i . . . 2 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 115 | pb fu . i y x . 2 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 116 | pb fu . i y x . 2 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 117 | pb fu . i y x . 2 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 118 | pb fu . i y x . 2 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 119 | pb fu . i y x . 2 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 120 | pb fu . i y x . 2 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 121 | pb fu . i y c . 2 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 122 | pb fu . i y c . 2 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 123 | pb fu . i y c . 2 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 124 | pb fu . i y c . 2 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 125 | pb fu . i y c . 2 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 126 | pb fu . i y c . 2 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 127 | pb fu . i . . . 4 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 128 | pb fu . i . . . 4 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 129 | pb fu . i . . . 4 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 130 | pb fu . i . . . 4 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 131 | pb fu . i . . . 4 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 132 | pb fu . i . . . 4 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 133 | pb fu . i y x . 4 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 134 | pb fu . i y x . 4 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 135 | pb fu . i y x . 4 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 136 | pb fu . i y x . 4 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 137 | pb fu . i y x . 4 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 138 | pb fu . i y x . 4 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 139 | pb fu . i y c . 4 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 140 | pb fu . i y c . 4 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 141 | pb fu . i y c . 4 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 142 | pb fu . i y c . 4 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 143 | pb fu . i y c . 4 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 144 | pb fu . i y c . 4 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 145 | pb fu . i . . . 8 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 146 | pb fu . i . . . 8 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 147 | pb fu . i . . . 8 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 148 | pb fu . i . . . 8 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 149 | pb fu . i . . . 8 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 150 | pb fu . i . . . 8 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 151 | pb fu . i y x . 8 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 152 | pb fu . i y x . 8 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 153 | pb fu . i y x . 8 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 154 | pb fu . i y x . 8 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 155 | pb fu . i y x . 8 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 156 | pb fu . i y x . 8 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 157 | pb fu . i y c . 8 | 32 8 8 8 . | 4 24 . | 64 16 16 16 16 | . . . |
| 158 | pb fu . i y c . 8 | 32 8 8 8 8 | 4 24 . | 64 16 16 16 16 | . . . |
| 159 | pb fu . i y c . 8 | 32 8 8 8 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 160 | pb fu . i y c . 8 | 32 8 8 8 8 | 4 24 8 | 64 16 16 16 16 | . . . |
| 161 | pb fu . i y c . 8 | 32 8 8 8 . | 4 . . | 64 16 16 16 16 | . . . |
| 162 | pb fu . i y c . 8 | 32 8 8 8 8 | 4 . . | 64 16 16 16 16 | . . . |
| 163 | pb fu . i . . . . | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 164 | pb fu . i . . . . | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 165 | pb fu . i . . . . | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 166 | pb fu . i y x . . | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 167 | pb fu . i y x . . | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 168 | pb fu . i y x . . | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 169 | pb fu . i y c . . | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 170 | pb fu . i y c . . | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 171 | pb fu . i y c . . | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 172 | pb fu . i . . . 2 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 173 | pb fu . i . . . 2 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 174 | pb fu . i . . . 2 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 175 | pb fu . i y x . 2 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 176 | pb fu . i y x . 2 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 177 | pb fu . i y x . 2 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 178 | pb fu . i y c . 2 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 179 | pb fu . i y c . 2 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 180 | pb fu . i y c . 2 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 181 | pb fu . i . . . 4 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 182 | pb fu . i . . . 4 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 183 | pb fu . i . . . 4 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 184 | pb fu . i y x . 4 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 185 | pb fu . i y x . 4 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 186 | pb fu . i y x . 4 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 187 | pb fu . i y c . 4 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 188 | pb fu . i y c . 4 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 189 | pb fu . i y c . 4 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 190 | pb fu . i . . . 8 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 191 | pb fu . i . . . 8 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 192 | pb fu . i . . . 8 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 193 | pb fu . i y x . 8 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 194 | pb fu . i y x . 8 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 195 | pb fu . i y x . 8 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 196 | pb fu . i y c . 8 | 16 5 6 5 . | 4 24 . | 64 16 16 16 16 | . . . |
| 197 | pb fu . i y c . 8 | 16 5 6 5 . | 4 24 8 | 64 16 16 16 16 | . . . |
| 198 | pb fu . i y c . 8 | 16 5 6 5 . | 4 . . | 64 16 16 16 16 | . . . |
| 199 | pb fu . i . . . . | . . . . . | . 24 . | . . . . . | . . . |
| 200 | pb fu . i . . . . | . . . . . | . 24 8 | . . . . . | . . . |
| 201 | pb fu . f . . . . | 16 16 . . . | 4 24 . | . . . . . | . . . |
| 202 | pb fu . f . . . . | 16 16 . . . | 4 24 8 | . . . . . | . . . |
| 203 | pb fu . f . . . . | 16 16 . . . | 4 . . | . . . . . | . . . |
| 204 | pb fu . f y x . . | 16 16 . . . | 4 24 . | . . . . . | . . . |
| 205 | pb fu . f y x . . | 16 16 . . . | 4 24 8 | . . . . . | . . . |
| 206 | pb fu . f y x . . | 16 16 . . . | 4 . . | . . . . . | . . . |
| 207 | pb fu . f y c . . | 16 16 . . . | 4 24 . | . . . . . | . . . |
| 208 | pb fu . f y c . . | 16 16 . . . | 4 24 8 | . . . . . | . . . |
| 209 | pb fu . f y c . . | 16 16 . . . | 4 . . | . . . . . | . . . |
| 210 | pb fu . f . . . . | 32 32 . . . | 4 24 . | . . . . . | . . . |
| 211 | pb fu . f . . . . | 32 32 . . . | 4 24 8 | . . . . . | . . . |
| 212 | pb fu . f . . . . | 32 32 . . . | 4 . . | . . . . . | . . . |
| 213 | pb fu . f y x . . | 32 32 . . . | 4 24 . | . . . . . | . . . |
| 214 | pb fu . f y x . . | 32 32 . . . | 4 24 8 | . . . . . | . . . |
| 215 | pb fu . f y x . . | 32 32 . . . | 4 . . | . . . . . | . . . |
| 216 | pb fu . f y c . . | 32 32 . . . | 4 24 . | . . . . . | . . . |
| 217 | pb fu . f y c . . | 32 32 . . . | 4 24 8 | . . . . . | . . . |
| 218 | pb fu . f y c . . | 32 32 . . . | 4 . . | . . . . . | . . . |
| 219 | pb fu . f . . . . | 32 16 16 . . | 4 24 . | . . . . . | . . . |
| 220 | pb fu . f . . . . | 32 16 16 . . | 4 24 8 | . . . . . | . . . |
| 221 | pb fu . f . . . . | 32 16 16 . . | 4 . . | . . . . . | . . . |
| 222 | pb fu . f y x . . | 32 16 16 . . | 4 24 . | . . . . . | . . . |
| 223 | pb fu . f y x . . | 32 16 16 . . | 4 24 8 | . . . . . | . . . |
| 224 | pb fu . f y x . . | 32 16 16 . . | 4 . . | . . . . . | . . . |
| 225 | pb fu . f y c . . | 32 16 16 . . | 4 24 . | . . . . . | . . . |
| 226 | pb fu . f y c . . | 32 16 16 . . | 4 24 8 | . . . . . | . . . |
| 227 | pb fu . f y c . . | 32 16 16 . . | 4 . . | . . . . . | . . . |
| 228 | pb fu . f . . . . | 64 32 32 . . | 4 24 . | . . . . . | . . . |
| 229 | pb fu . f . . . . | 64 32 32 . . | 4 24 8 | . . . . . | . . . |
| 230 | pb fu . f . . . . | 64 32 32 . . | 4 . . | . . . . . | . . . |
| 231 | pb fu . f y x . . | 64 32 32 . . | 4 24 . | . . . . . | . . . |
| 232 | pb fu . f y x . . | 64 32 32 . . | 4 24 8 | . . . . . | . . . |
| 233 | pb fu . f y x . . | 64 32 32 . . | 4 . . | . . . . . | . . . |
| 234 | pb fu . f y c . . | 64 32 32 . . | 4 24 . | . . . . . | . . . |
| 235 | pb fu . f y c . . | 64 32 32 . . | 4 24 8 | . . . . . | . . . |
| 236 | pb fu . f y c . . | 64 32 32 . . | 4 . . | . . . . . | . . . |
| 237 | pb fu . f . . . . | 64 16 16 16 16 | 4 24 . | . . . . . | . . . |
| 238 | pb fu . f . . . . | 64 16 16 16 16 | 4 24 8 | . . . . . | . . . |
| 239 | pb fu . f . . . . | 64 16 16 16 16 | 4 . . | . . . . . | . . . |
| 240 | pb fu . f y x . . | 64 16 16 16 16 | 4 24 . | . . . . . | . . . |
| 241 | pb fu . f y x . . | 64 16 16 16 16 | 4 24 8 | . . . . . | . . . |
| 242 | pb fu . f y x . . | 64 16 16 16 16 | 4 . . | . . . . . | . . . |
| 243 | pb fu . f y c . . | 64 16 16 16 16 | 4 24 . | . . . . . | . . . |
| 244 | pb fu . f y c . . | 64 16 16 16 16 | 4 24 8 | . . . . . | . . . |
| 245 | pb fu . f y c . . | 64 16 16 16 16 | 4 . . | . . . . . | . . . |
| 246 | pb fu . f . . . . | 128 32 32 32 32 | 4 24 . | . . . . . | . . . |
| 247 | pb fu . f . . . . | 128 32 32 32 32 | 4 24 8 | . . . . . | . . . |
| 248 | pb fu . f . . . . | 128 32 32 32 32 | 4 . . | . . . . . | . . . |
| 249 | pb fu . f y x . . | 128 32 32 32 32 | 4 24 . | . . . . . | . . . |
| 250 | pb fu . f y x . . | 128 32 32 32 32 | 4 24 8 | . . . . . | . . . |
| 251 | pb fu . f y x . . | 128 32 32 32 32 | 4 . . | . . . . . | . . . |
| 252 | pb fu . f y c . . | 128 32 32 32 32 | 4 24 . | . . . . . | . . . |
| 253 | pb fu . f y c . . | 128 32 32 32 32 | 4 24 8 | . . . . . | . . . |
| 254 | pb fu . f y c . . | 128 32 32 32 32 | 4 . . | . . . . . | . . . |
| 255 | pb fu . f . . . . | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 256 | pb fu . f . . . . | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 257 | pb fu . f . . . . | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 258 | pb fu . f y x . . | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 259 | pb fu . f y x . . | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 260 | pb fu . f y x . . | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 261 | pb fu . f y c . . | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 262 | pb fu . f y c . . | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 263 | pb fu . f y c . . | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 264 | pb fu . f . . . 2 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 265 | pb fu . f . . . 2 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 266 | pb fu . f . . . 2 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 267 | pb fu . f y x . 2 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 268 | pb fu . f y x . 2 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 269 | pb fu . f y x . 2 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 270 | pb fu . f y c . 2 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 271 | pb fu . f y c . 2 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 272 | pb fu . f y c . 2 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 273 | pb fu . f . . . 4 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 274 | pb fu . f . . . 4 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 275 | pb fu . f . . . 4 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 276 | pb fu . f y x . 4 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 277 | pb fu . f y x . 4 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 278 | pb fu . f y x . 4 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 279 | pb fu . f y c . 4 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 280 | pb fu . f y c . 4 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 281 | pb fu . f y c . 4 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 282 | pb fu . f . . . 8 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 283 | pb fu . f . . . 8 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 284 | pb fu . f . . . 8 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 285 | pb fu . f y x . 8 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 286 | pb fu . f y x . 8 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 287 | pb fu . f y x . 8 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
| 288 | pb fu . f y c . 8 | 32 11 11 10 . | 4 24 . | . . . . . | . . . |
| 289 | pb fu . f y c . 8 | 32 11 11 10 . | 4 24 8 | . . . . . | . . . |
| 290 | pb fu . f y c . 8 | 32 11 11 10 . | 4 . . | . . . . . | . . . |
+-----+-------------------------+-----------------+----------+-----------------+----------+
| | visual | color | ax dp st | accum | layer |
| id | tp ac gd fm db sw st ms | sz r g b a | bf th cl | sz r g b a | ov un sw |
+-----+-------------------------+-----------------+----------+-----------------+----------+

Relic
11-10-2006, 04:24 AM
but no :GL_NV_gpu_program4
NV_fragment_program4
GL_EXT_geometry_shader4
NV_geometry_program4
.........extensions
Read the thread again, five posts above yours.

ebray99
11-10-2006, 06:27 AM
Knackered and Korval, maybe I can get Barthold or Michael Gold to give a brief update on the GL3 goings on... I have particular bits I'm interested in, but they have a much better holistic view of how things are progressing.I'm also very interested in this. Will there be an update on the OpenGL site regarding this? Perhaps something in the next pipeline article?

Also, big thanks for the new extensions! When I saw the card come out, I thought to myself, "now I just have to wait a few months to get at it's features." When I saw the extensions posted the next day... well... lets just say I'm really wanting one now. Many thanks to everyone at NVidia for the great hardware and GL support!

Kevin

Korval
11-10-2006, 09:25 AM
my Geforce 8800 GTX driver: 9702 opengl extensions info:That's a very large post. It'd be better to dump this on Delphi3d.net and just post a link to it.

elFarto
11-10-2006, 09:27 AM
I have a question. How many, if any, of these shiny new features are going to be available to older cards. I realise that the geometry shaders will only be available to new hardware.

Regards
elFarto

Korval
11-10-2006, 11:33 AM
I have a question. How many, if any, of these shiny new features are going to be available to older cards. I realise that the geometry shaders will only be available to new hardware.The big PDF has a large, detailed table about which extensions are supported where.

But, to sum up, if you don't have a G80, you only get framebuffer_multisample and _blit. None of the new extensions are for you.

barthold
11-10-2006, 11:59 AM
Originally posted by ebray99:

Knackered and Korval, maybe I can get Barthold or Michael Gold to give a brief update on the GL3 goings on... I have particular bits I'm interested in, but they have a much better holistic view of how things are progressing.I'm also very interested in this. Will there be an update on the OpenGL site regarding this? Perhaps something in the next pipeline article?

Kevin Yes, the ARB has been very busy! The second edition of the OpenGL Pipeline should be out soon with more information. But I'll post an update in this forum, hopefully today.

Barthold
ARB chair

zed
11-10-2006, 12:48 PM
The big PDF has a large, detailed table about which extensions are supported where.seems my nv4x doesnt do that much more than my nv3x (not complaining mind its a sweet card)

btw big ups to all the ppl working on gl, i know a lot of ppl give u **** about glacial etc (personally i like a slow pace eg perhaps a new extension spec released every couple of months instead of dumping 10 or so all at once, its to much to digest at once)

i know a lot of ppl associasted with gl are doing it as a labour of love + not just as a job
big hugs all round
better stop now afore i break out the hankies

Korval
11-10-2006, 01:07 PM
seems my nv4x doesnt do that much more than my nv3x (not complaining mind its a sweet card)Of course not; nv4x was just a refresher part. The nv3x line (GeForceFX) could do quite a bit, but had horrible performance when doing any of it. The nv4x line exists so that those features can actually be used rather than be purely theoretical.

knackered
11-10-2006, 01:17 PM
nv3x could not sample textures in a vertex shader.

Korval
11-10-2006, 02:16 PM
nv3x could not sample textures in a vertex shader.True, but that's not something you see on an extension list (well, besides the NV assembly ones).

Mars_999
11-10-2006, 02:23 PM
Just wanted to say that Delphi3D has posted my GLInfo report on my 8800GTX. So if you want the specs go and get them.

MZ
11-10-2006, 03:37 PM
Originally posted by Zengar:
Actually, this extension only gives you the current primitive number. IMHO, it is more convenient and flexible then DX9 instancing. Actually, Nvidia was working on a more DX9-like extension, looks like they gave it up. But as there is little need for it in OpenGL, why not? Actually, I'm a bit surprised that there is any instancing extension for g80. I thought instancing on next gen cards would be done entirely with the geometry shader. So when I saw "EXT_draw_instanced" in the list extracted from driver, my first thought was that the awaited d3d9-style instancing have found its way to the next major driver update.

Korval
11-10-2006, 06:29 PM
I thought instancing on next gen cards would be done entirely with the geometry shader.Given the description of the geometry shader I read in the spec, it doesn't seem to be able to do real instancing. It doesn't have full run of the incoming data, for example; it only operates on relatively small segments of the data.

I suppose you could sit on one triangle, looping and emitting numerous instances of the triangle, then move on to the next. But I can't imagine this being faster than a hardware solution.

barthold
11-10-2006, 07:23 PM
Originally posted by Korval:

I thought instancing on next gen cards would be done entirely with the geometry shader.Given the description of the geometry shader I read in the spec, it doesn't seem to be able to do real instancing. It doesn't have full run of the incoming data, for example; it only operates on relatively small segments of the data.

I suppose you could sit on one triangle, looping and emitting numerous instances of the triangle, then move on to the next. But I can't imagine this being faster than a hardware solution. The idea of the EXT_draw_instanced spec is that the vertex shader has access to the ID of the current instance. You can write a vertex shader and use that ID to look up the per-instance data (for example, a modelviewprojection matrix) in for example a vertex texture, a texture buffer object, or a bindable uniform array. This provides you full flexibility. All that the GL API provides is two new draw calls that loop N times over the single set of geometry that you pass it. For each loop, the instance ID in the vertex shader is incremented.

Barthold
(With my NVIDIA hat on)

knackered
11-11-2006, 02:18 PM
That is really nice. Such a lovely simple solution.

AlexN
11-12-2006, 01:43 PM
Does the G80 support mixing render target bit depths or multisample modes for multiple render targets?

Mars_999
11-12-2006, 04:21 PM
For anyone at Nvidia.

With the new G80 and regarding floating point textures and samplers for GLSL. Can you now use the GL_LUMINANCE32F_ARB texture type and texture2D()? or are we still limited to texture rect only?

Relic
11-13-2006, 03:08 AM
Originally posted by Mars_9999:
With the new G80 and regarding floating point textures and samplers for GLSL. Can you now use the GL_LUMINANCE32F_ARB texture type and texture2D()? or are we still limited to texture rect only?What was your problem before?
You have a GF5?
Non-power-of-two textures are supported since GF6 and LUMINANCE32F handling shouldn't be special, except for the expansion to RGBA. In a shader you could also use any other one component FP32 format.

Mars_999
11-13-2006, 03:22 AM
So everything that has NPOT support is ok to use the texture2D() with LUMINANCE32F or single component types. Thanks for clearing this up.

pbrown
11-13-2006, 04:58 AM
Originally posted by AlexN:
Does the G80 support mixing render target bit depths or multisample modes for multiple render targets? Yes to render target bit depths and formats. No to multisample modes. I assume by multisample modes, you mean 2x vs. 4x vs. 8x vs. the new CSAA modes.

AlexN
11-13-2006, 08:07 AM
Originally posted by pbrown:

Originally posted by AlexN:
Does the G80 support mixing render target bit depths or multisample modes for multiple render targets? Yes to render target bit depths and formats. No to multisample modes. I assume by multisample modes, you mean 2x vs. 4x vs. 8x vs. the new CSAA modes. Thanks, that's great. I was more concerned about mixing a non-multisampled render target with one that is, but it sounds like that is not possible?

Dee.cz
11-13-2006, 09:11 AM
Are updated headers available?

Mars_999
11-13-2006, 11:42 AM
I would like to know also when the glext.h file with the new extensions will be available?

Slang
11-13-2006, 11:28 PM
You can download a modified version of GLEW which supports GeForce 8 series OpenGL extensions at:
http://www.clockworkcoders.com/oglsl/

Addendum:
The updated include files are now available at the NVIDIA developer website.
http://developer.nvidia.com/object/nvidia_opengl_specs.html

Dee.cz
11-14-2006, 04:57 AM
Thanks!

soconne
11-15-2006, 06:44 PM
Does anybody know if this next version of OpenGL will finally support a feature similar to DirectX's BaseVertexIndex when binding an index array?

For instance if you have an index array {0, 1, 2, 3, 4} and you set BaseVertexIndex = 10, then when sent to the graphics card the vertices {10, 11, 12, 13, 14} are used.

I've been waiting soooo long for this to be supported. Hopefully people other than myself find this a must have feature.

Mars_999
11-15-2006, 06:51 PM
Originally posted by soconne:
Does anybody know if this next version of OpenGL will finally support a feature similar to DirectX's BaseVertexIndex when binding an index array?

For instance if you have an index array {0, 1, 2, 3, 4} and you set BaseVertexIndex = 10, then when sent to the graphics card the vertices {10, 11, 12, 13, 14} are used.

I've been waiting soooo long for this to be supported. Hopefully people other than myself find this a must have feature. Ditto on that one...

soconne
11-16-2006, 06:47 AM
There isn't a way to write an extension to do what we need is there? Since DirectX already has the functionality, couldn't a modified OpenGL driver be written which takes advantage of that? I don't see why it would be difficult for Nvidia or ATI to do it.

knackered
11-16-2006, 08:40 AM
If that ability is ever going to be added (which it should) it will be in GL3.0, with the new object model, agreed by the whole ARB, not just nvidia.

pbrown
11-16-2006, 08:40 AM
Originally posted by soconne:
There isn't a way to write an extension to do what we need is there? Since DirectX already has the functionality, couldn't a modified OpenGL driver be written which takes advantage of that? I don't see why it would be difficult for Nvidia or ATI to do it. Can either of you guys that "voted" for such a feature offer an example of how it would make life easier for you? It doesn't seem like it helps much for DrawArrays-style rendering, except maybe allowing for more modular code. For DrawElements, when is it not possible/OK to just factor this base offset into the indices? I can certainly see how something like this could be useful, I'm just not sure how useful.

Such an extension is certainly possible, but besides driver maintenance, there are various other complications: interaction with vertex ID, interaction with restart indices, all the different APIs (DrawArrays, DrawElements, ArrayElement, MultiDraw*). Such an extension would make sense if its value justifies the driver work involved.

Mars_999
11-16-2006, 09:29 AM
Here are the threads that I can remember that talk about this


http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=012219

http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=014659

http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=012219;p=2#0000 78

V-man
11-16-2006, 09:49 AM
I think it's rather simple.
The idea is to pack lots of objects into a large VBO.
For example, make 1 large VBO and another large IBO.

Read model #1 from disk, put vertices into VBO, put
indices in IBO.
Read model #2 from disk, put vertices into VBO, put indices in IBO.

Yes, we are using ushort for index.
Indices for model #2 need to be offsetted or we need to make calls to glVertexArray and the other gl****Array

I am offsetting with my own code. It's not such a big issue, but if the feature is available for D3D, why not GL?

soconne
11-16-2006, 10:00 AM
The problem I am having that requires this is my current terrain rendering implementation.

I have a 129x129 terrain page that is only the height values. I store this in one of the vertex attribute arrays. So for a 1025x1025 terrain I would have 16 of these, 8x8.

I then have a 129x129 xz patch that act as x, z coordinates. Inside the vertex shader I grab the appropriate y value from the above attribute array.

I then define several 33x33 patches that make up the 129x129 page. For each 33x33 patch, it indexes into an index buffer containing the correct precomputed indices for whatever LOD level the patch is at.

Currently after choosing the correct indices, I have to manually go through and offset the indice values on the CPU to correctly point to the right vertices in the page. This also prevents me from having the index buffer be stored on the GPU.

But if OpenGL had a BaseVertexIndex extension I could simply specify some offset, in this case 33, and for each 33x33 patch, their indices would automatically be offset to the correct vertex id once they reach the gpu.

And no, you cannot accomplish the same thing by using glVertexPointer. That would assume that your vertex buffers are aligned such that for each 33x33 patch, all its x, y, z values are stored consecutively. So it would be (33x33), (33x33), (33x33)....

But since this is not the case, and the 129x129 vertex buffer is simply stored (129x129) offsetting in glVertexPointer won't work.

pbrown
11-16-2006, 10:09 AM
Originally posted by V-man:
Indices for model #2 need to be offsetted or we need to make calls to glVertexArray and the other gl****Array

I am offsetting with my own code. It's not such a big issue, but if the feature is available for D3D, why not GL? Right, it seems that index offsetting is easy enough in such cases that it's only a minor annoyance. Perhaps a stronger argument might be to allow developers to unify OpenGL and D3D renderers, if they support both. The main argument not to do something like this is that it's one more code path to implement and verify in the driver, and one more thing that can break.

If we decided to do such an extension, I agree that it would make sense to do this as a multi-vendor extension and/or OpenGL 3.0, schedule permitting.

Korval
11-16-2006, 10:58 AM
I then define several 33x33 patches that make up the 129x129 page. For each 33x33 patch, it indexes into an index buffer containing the correct precomputed indices for whatever LOD level the patch is at.Isn't that going to create a lot of draw calls? I mean, for each patch, you've basically got to make 16 draw calls instead of just one for a patch.

And I know GL's draw calls are cheaper than D3D's, but they're not free. Your indices wouldn't break the 16-bit boundary, so you wouldn't need to use ints for them. You'd only lose 15552 * 2, or 31104 bytes; hardly worth mentioning.

In your case, I think it would be better to sacrifice a small quantity of memory than to make over a dozen draw calls like that.

soconne
11-16-2006, 11:01 AM
Well I worried about having to refill index buffers for each page every frame. Then for each index buffer as I'm filling it, having to offset the index values. Is this worth it?

Flavious
11-16-2006, 12:13 PM
I think there are better ways to render terrains on modern graphics cards, especially the NV40+ hardware, like clip-mapping. Clip-mapping allows you to create static vertex/index buffer footprints and use uniforms to scale and translate these tiles while sampling the per-vertex elevation data, all from within the shader. Right now this requires the ability to sample textures in vertex shaders, for best performance, but I would think equivalent functionality (currently only NV40+) should be ubiquitous in the near future. I imagine the situation gets even better with G80+ hardware.

Korval
11-16-2006, 01:25 PM
Well I worried about having to refill index buffers for each page every frame.You wouldn't have to; you just reuse the index buffer.

Each page lives in a separate buffer object, yes? And the shared X,Z data is in its buffer object, right? So all you should need to do to render a page is to bind the new Y buffer object, along with the color/texture coordinates (assuming the text coords change), and make another draw call.

Or, do what Flavious said, except that you substitute the vertex texture access with simply getting the value from an attribute (the Y buffer object). They're both the same.

Jan
11-16-2006, 01:37 PM
I don't think, the fact, that you COULD do terrain rendering differently is a valid argument against a feature, for which terrain-rendering was ONE example, that it could improve.

There are things, that could definitely benefit from a base-index.

Also, IMO, geometry clipmaps are not really such a great way to render terrains, they are just ONE way to do it. I don't know of any real application, that uses the GPU based method, so i don't think, one can say, that it is better than all the other methods that are successfully used today.

Just my 2 cent, but actually the topic has been discussed to death in the other threads some time ago.

Jan.

Korval
11-16-2006, 02:35 PM
I don't think, the fact, that you COULD do terrain rendering differently is a valid argument against a feature, for which terrain-rendering was ONE example, that it could improve.And no one is claiming that it is. Only that this particular use seems specious.

Dark Photon
11-16-2006, 03:20 PM
flavious:
I think there are better ways to render terrains on modern graphics cards, especially the NV40+ hardware, like clip-mapping...Perhaps. But it's patented by Microsoft. What are the terms/cost of using this algorithm?

Jan
11-17-2006, 01:00 AM
Korval: My post wasn't a reply to yours, it was more directed at flavious.

When someone asks for an example-use for a feature, then you can't dismiss the feature, only because the example might not be perfect.
That's what i wanted to point out.

Jan.

Korval
11-17-2006, 09:09 AM
When someone asks for an example-use for a feature, then you can't dismiss the feature, only because the example might not be perfect.
That's what i wanted to point out.But noone is dismissing the feature. Not Flavious, not me, nobody.

knackered
11-18-2006, 03:23 AM
It seems perfectly reasonable, and in fact looks weird without it, to say "the part of the currently bound vertex buffer my indices refer to is this".
At the moment, my renderer has to manually walk the indices offsetting them, but only if the draw device is OpenGL and not D3D. So I'm actually changing the mesh data in my database because of what can only be described as a limitation in OpenGL. There is no other part in my system where I have to do this.
If you're refactoring the GL API then I cannot for the life of me see why you would not add this required parameter....for parameter is all it is if you're rewriting the whole drawing API.

soconne
11-18-2006, 06:52 AM
Couldn't have said it better knackered.

knackered
11-20-2006, 12:14 AM
I get the feeling this is like pissing in the wind though, soconne. Lots of active and experienced developers put forward an extensive, well supported and reasoned argument, and what do you get?

al_bob
11-25-2006, 12:39 PM
At the moment, my renderer has to manually walk the indices offsetting them, but only if the draw device is OpenGL and not D3D. Why can't you just resend calls to glVertexPointer(), glColorPointer(), etc, offsetting them by the required index offset?

You don't have to walk through the index list this way.

knackered
11-25-2006, 02:13 PM
Efficiency, bob, efficiency and performance. Have you tried reading the discussions there has already been on this subject? They're even linked to via this thread...your question is answered in much greater detail there.
Or are you just trying to be funny?

al_bob
11-28-2006, 02:10 PM
Have you tried reading the discussions there has already been on this subject? They're even linked to via this thread...your question is answered in much greater detail there.
Or are you just trying to be funny?I apologies if I have mistakenly given you the impression that I have read every thread on this board in the last 2.5 years, and every post in all those threads.

I will definitely attempt to be more omnipresent next time.


Efficiency, bob, efficiency and performance.I understand it saves you a few lines of code, but does it really improve performance? Have you measured it? What is the actual cost of calling glVertexPointer() on a VBO?

The threads that were linked to above don't seem to answer that. There's only some vague allusion to some unspecified document that apparently says to not do that.

Korval
11-28-2006, 02:29 PM
The threads that were linked to above don't seem to answer that.Hey, you can't ask people to prove that a feature is needed before demanding it! It's in D3D, so it's worthy of GL inclusion a priori.

[ /sarcasm ]

Kidding aside, there is some legitimate question as to whether it would be a performance gain or just a waste of the ARB's time. The only way to be sure would be if the IHVs from the various companies came out and said if gl*Pointer readjustment calls are significant performance sinks or not.

Personally, considering the small nature of the feature, and the fact that hardware (or something) must support it since D3D does, I'd just prefer they expose it and be done with it.

santyhamer
11-28-2006, 03:06 PM
I wonder if all these new extensions are going to be well documented ( + examples of use ) in the future Khronos OpenSDK!

soconne
11-28-2006, 07:57 PM
Originally posted by Korval:

The threads that were linked to above don't seem to answer that.Hey, you can't ask people to prove that a feature is needed before demanding it! It's in D3D, so it's worthy of GL inclusion a priori.

[ /sarcasm ]

Kidding aside, there is some legitimate question as to whether it would be a performance gain or just a waste of the ARB's time. The only way to be sure would be if the IHVs from the various companies came out and said if gl*Pointer readjustment calls are significant performance sinks or not.

Personally, considering the small nature of the feature, and the fact that hardware (or something) must support it since D3D does, I'd just prefer they expose it and be done with it. Actually the performance gain comes from moving the calculations from the CPU to the GPU. If you read my post about the terrain rendering example you'll see that. Plus the cost of moving the offsetting of indices to the GPU costs virtually nothing since each would be offset by a constant value.

knackered
11-29-2006, 01:22 AM
Originally posted by al_bob:
I apologies if I have mistakenly given you the impression that I have read every thread on this board in the last 2.5 years, and every post in all those threads.

I will definitely attempt to be more omnipresent next time.I expect you to have read the thread you are commenting on. Is that really too much to ask, bob?

LoopinFool
11-29-2006, 10:55 AM
The original post mentioned a "GL_EXT_ycbcr_422" extension. I don't see that one listed anywhere in nVidia's documents or header files.

Does anyone know about it? We would love to have a component video texture format and not have to write ugly shaders and lie about image sizes. The cards all have built-in hardware to do RGB<->YUV conversions. We'd just like it exposed in OpenGL.

Thanks,
- LoopinFool