PDA

View Full Version : wiki topic: nvidia gffx info



zed
04-28-2006, 05:31 PM
im willing to write a wiki topic about the gffx + opengl, first off focusing on what it cant do

* FBO 16depth with a color attachment (must be 24bit depth)
* FBO with multisample (though no card does this yet i think)
* accessing textures in the vertex shader
* NPOT textures (ARB_texture_rectangle only)
* proper branching in the shaders

any others / corrections?
nows the time afore i commit this to paper

zed

knackered
04-29-2006, 06:39 AM
I really think this is something that belongs in delphi3d's glinfo registry, with a link posted in the wiki. It's about time Tom Nuydens updated his program to query these kind of limitations - it would be a simple matter of adding some test cases and timing their execution.

Hybris
04-29-2006, 08:15 AM
*No MRT

zed
04-29-2006, 04:57 PM
Originally posted by knackered:
I really think this is something that belongs in delphi3d's glinfo registry, with a link posted in the wiki. It's about time Tom Nuydens updated his program to query these kind of limitations - it would be a simple matter of adding some test cases and timing their execution. i will stick a link to delphi3d's glinfo registry.
the great thing about a wiki is its not reliant on a single person.
ie its prolly to much to ask for poor ol tom to continually maintain it, also i disagree about it being simple to write up test cases for this, i see it being a huge + difficult project.

i just copied this, now are these conformance tests still being done? all links i found seem to be about quite old gl eg 1.2

'What are the conformance tests?

The conformance tests are a suite of programs that judge the success of an OpenGL implementation. Each implementor is required to run these tests and pass them in order to use the OpenGL registered trademark with their implementation. Passing the conformance tests ensures source code compatibility of applications across all OpenGL implementations. '

thanks hybris

Brolingstanz
04-29-2006, 06:48 PM
I'm sure Nvidia will appreciate a list of all the things their cards can't do :-D.

I can see the value of a good "missing in action" list, I suppose. On second thought, why do we need this?

ChiefWiggum
04-30-2006, 02:41 AM
Maybe Nvidia will get off their hairy arses and make a card that does multisample with float FBO, if they see it on a list as an important thing theyre missing :D

On the other hand maybe ATI will get off their own hairy arse and realise that doing floating point texturing without filtering is a waste of time!

Just a thought :D

knackered
04-30-2006, 05:51 AM
Originally posted by zed:
the great thing about a wiki is its not reliant on a single person.
ie its prolly to much to ask for poor ol tom to continually maintain it, also i disagree about it being simple to write up test cases for this, i see it being a huge + difficult project.The purpose of a wiki is not to provide 100% documentation for something, it is to provide an overview of a topic and provide links to independent sources and resources. If you put this caps list into the wiki we then have one more source data to go out of date, when there's already a perfectly good and well known source. Tom doesn't have to maintain anything, that's the purpose of his glinfo app, it does all the work for him. He's a keen proponant of OpenGL, and so if he ever gets tired of serving his glinfo registry, he will take measures to transfer it to opengl.org or whatever, I'm pretty sure of that.
To gleen the additional information you/we require, Tom has a relatively simply job to update his glinfo program.
Once again, I don't think the purpose of the wiki is to duplicate information already available elsewhere, it's to gather the links to this information together, with some dialog grouping it all together.

zed
04-30-2006, 08:04 PM
On second thought, why do we need this?2 reasons
A/ some me/you time by trying to do something that your card aint capable of
B/ im nearly ready for the 3rd beta release of my game (it wont work on ati cards since ive disabled support for them, cause ive run into problems before with my stuff not working on them )
having a list of a potenetual problems or unsupported areas would be extremely helpful for us developers.

The purpose of a wiki is not to provide 100% documentation for somethingIIRC one main idea behind the opengl wiki ( when it was motted a few months ago ) was as a replacement for the faq.

If you put this caps list into the wiki we then have one more source data to go out of datemate :) the great benifit of the wiki is practically anyonecan maintain it, thus it will be more uptodate (on average) than a source maintained by a single person (as im sure u know)

when there's already a perfectly good but it doesnt display all the info i want to know eg
* FBO 16depth with a color attachment (must be 24bit depth)
* FBO with multisample (though no card does this yet i think)

Korval
04-30-2006, 11:35 PM
To gleen the additional information you/we require, Tom has a relatively simply job to update his glinfo program.That's not really the point.

We can't control whether or not Tom updates his code. Maybe he never wants glinfo to do what you suggest; maybe he thinks that dissiminating such information is the responsibility of IHVs.

We can, however, control what goes up on the Wiki. Since the purpose of either method is to dissiminate the information, it makes sense for us to do it and for us to petition Tom to update glinfo. If he doesn't, then we have a fallback. And if he does, then we can delete it from the wiki and link to it instead.

tamlin
05-01-2006, 05:23 AM
"maybe he thinks that dissiminating such information is the responsibility of IHVs."

Whether or not Tom is thinking this, I for one think this is the responsibility of any commercial OpenGL driver vendor - to fully (!) define this for every (!) hardware that driver is to "support".

Not doing so is effectively forcing everyone to buy something effectively "unknown" and then personally test it before knwoing what they have really bought. I leave it to the reader to decide how this is considered in your jurisdiction.

I think the major vendors are currently... well, I can't express it in any other word than "*******s", for not fully specifying this. They put the burden on me (as a user) to find out what a specific combo of driver+completely_undocumented_hardware is "supporting".

V-man
05-01-2006, 08:53 AM
Are you sure there isn't a pdf somewhere on NV's site?
Still, it would be good to have this kind of info on the implementation specific part. This kind of info only appears when somebody comes here and asks about his problem, then the thread gets barried and forgotten.
A bugs section would be good too.

ebray99
05-01-2006, 08:59 AM
Hmmm... I've been using MRTs, non-power of two render targets with FBO, and dynamic control flow for some time now (about 3-6 months?) and they've been working correctly for me. So maybe I'm just not seeing it?

Kevin

knackered
05-01-2006, 11:20 AM
Well, if that's the consensus, so be it.
I think it makes more sense to automate the process, and standardise the results - rather than have lots of messy entries sprawled over the wiki, which makes them difficult to search for or make sense out of, and which *will* be out of date as soon as the next generation of cards becomes peoples main focus.
The glinfo registry is one of the better ideas I've seen in my time in this community.
BTW, is Tom still alive? I haven't seen him contribute to these forums for a long time, and his site hasn't been updated since June last year.

zed
05-01-2006, 04:14 PM
Hmmm... I've been using MRTs, non-power of two render targets with FBO, and dynamic control flow for some time now (about 3-6 months?) and they've been working correctly for me. So maybe I'm just not seeing it?i was talking about the nvidia gffx (nv3x) line of cards

ebray99
05-01-2006, 04:53 PM
Ah, I'm dumb... I understood this to be discussing driver limitations as opposed to hardware limitations. Please ignore me. =)

Kevin B

Brolingstanz
05-01-2006, 07:50 PM
A/ some me/you time by trying to do something that your card aint capable of
B/ im nearly ready for the 3rd beta release of my game (it wont work on ati cards since ive disabled support for them, cause ive run into problems before with my stuff not working on them )
having a list of a potenetual problems or unsupported areas would be extremely helpful for us developers.I gotcha. So instead of having to muck about with the extension string, registry or something, a quick glimpse at the wiki will tell us whether a certain base functionality is supported on a given card. Or in other terms, this is a way to quickly track down those hard to find details that tend to sneak off into dark cracks and crannies of the world; a shader-model synopsis, of sorts.

Glad I thought of it!

That GLinfo hardware registry is mighty sweet indeed. I can understand the temptation to make that the repository for this sort of thing, even though the breadth of information might eventually extend beyond what could be reasonably expected of one person to maintain, especially if a bug section was added.

P.S. I have dibs on the first copy of your game :-)

zed
05-02-2006, 02:56 AM
ok, ive asked for an account with the wiki guys (btw wiki guys billybolluxbouncingballs is me) + will upload the following data (or someone esle can upload it they wish) under here
http://www.opengl.org/wiki/index.php/Hardware_specifics:_NVidia

im not to sure about having driver bugs in though cause of it being open for abuse eg 'gffx is only limited to 60hz framerate' or bugs along the lines of 'strangest error' but anyways

// Hardware limitations

* The EXT_depth_bounds_test extension is only available with gffx5900 + 5950 the rest of the gffx line aint capable
* Theres no Multiple Render Targets ie ( GL_MAX_DRAW_BUFFERS == 1 )
* You cant attach a 16depthtexture to a FBO with a color attachment ( it must be 24bit depth ), though having a 16bit depth FBO by itself is ok.
* FBO with multisample are not supported
* Vertex textures are not supported
* NPOT textures aint supported in hardware. Instead for non power of 2 sized textures you have to use ARB_texture_rectangle / GL_NV_texture_rectangle, unfortunatly ATI cards dont support these.
* Theres no proper branching support in the shaders, eg with a if else statement, both paths will be executed and the non applicable result will be ignored. ie theres no performance increase from using them prolly a performance decrease.
* With glsl the noise() function isn't implemented
* With glsl gl_FrontFacing isnt supported

// Driver bugs

with glsl fract( .. ) isnt working in the vertex shader

info gleaned from experimentation and
NVIDIA_OpenGL_2.0_Support.pdf



P.S. I have dibs on the first copy of your game :-)dont know about first but send me an email if u wanna test the next version (i dont think ill make it available for general release, as its still buggy)

meanwhile u can try this (nvidia only) http://www.filefactory.com/?14d5c4
btw ive speed this up now by a factor of 2 (also better quality) and with possible improvements of 3-4x to come.

sqrt[-1]
05-02-2006, 05:25 AM
Your app crashes on my Nvidia 6800 (81.94 drivers)
- Black screen on startup then Boom!

zed
05-02-2006, 06:28 PM
sorry (the whole app was a hack, ie it started off just as a terrain test + then i added the grass etc + it just grew) by any chance does your card have 128mb of memory?
a 6800 sounds like u would have 256mb.
if u have 128 try turning off antialising in the drivers (it wont look good but may work)

Brolingstanz
05-02-2006, 09:39 PM
dont know about first:(

Brolingstanz
05-02-2006, 10:34 PM
Nice demo, Zed. I get around 15-25 fps on a 6800 (84.12). The rocks are very cool, like the grass and all the shadows on everything, too ;-).

I thought I had a crash, but it was just an inordinately long start-up time :D .

zed
05-03-2006, 12:13 AM
"I thought I had a crash, but it was just an inordinately long start-up time"
yeah sorry i should of mentioned that, it precalculates quite a bit but saves it on disk , so next time its a faster startup keys 1-6 turn things off/on.
though like i mensionted ive improved that app a bit now (better cascading shadowmap implementation, + also faster )
anyways to whet your appetite about CC ive just stuck up some new screenshots (last 4)
hmmm just looking now, noticed an error in the appleseeds no being lit correct, it never ends :( . also im starting a new job soon working from 10pm->6am so i doing know how this is gonna affect my ability to code (so it might be a while before the next demo comes out)
http://uk.geocities.com/sloppyturds/CaptainCourgette/GameMedia.html

knackered
05-03-2006, 05:47 AM
zed, could you let us know how you've done your cascading shadowmaps?

zed
05-03-2006, 02:47 PM
theyre pretty common sense theres no tricks involved im using 3x2048 textures in that demo i think (that is using the same texture 3x)
what specifically do u want to know?
FWIW someones writing a paper on the subject ( i dont know when it will be out though )

knackered
05-04-2006, 03:20 AM
specifically, how do you decide which map to sample from for a given object/fragment?
Or do you use multipass?

zed
05-04-2006, 03:44 PM
well u only have sample from one shadowmap since u dont wanna create eg 3-5x 2048x2048x24bit uncompressed shadowmap textures just for the suns shadows (which is a lot of memory)

for each lights frustum (from the CSMs) render all the geometry within to a depthmap + then switch to the cameras viewpoint + render all the light recieving geometry (usually the same geometry as the shadowcasters) ie just like normal shadowmapping.
repeat this with each of the CSM frustum's

start with the closest frustum to the camera (best quality shadows since they cover the smallest area) and work outwards

Eric Lengyel
05-04-2006, 11:25 PM
Originally posted by zed:

// Hardware limitations

* The EXT_depth_bounds_test extension is only available with gffx5900 + 5950 the rest of the gffx line aint capable
I'm not sure about this one any more. I know it was the case that the driver only exposed this on 5900 when it came out, but it appears to be showing up on 5600/5700 now.

knackered
05-05-2006, 03:09 AM
Originally posted by zed:
well u only have sample from one shadowmap since u dont wanna create eg 3-5x 2048x2048x24bit uncompressed shadowmap textures just for the suns shadows (which is a lot of memory)Well that's 36mb, which isn't all that much memory to devote to shadows. The cheap card sitting in my current machine has 256mb of memory, and that's today....next year it will be even less of a problem.


Originally posted by zed:
for each lights frustum (from the CSMs) render all the geometry within to a depthmap + then switch to the cameras viewpoint + render all the light recieving geometry (usually the same geometry as the shadowcasters) ie just like normal shadowmapping.
repeat this with each of the CSM frustum's......Wow, that's a lot of rendering each frame.
The method I've been thinking about is nesting the shadowmaps (as implied by carmack), and updating them over many frames rather than every frame if only the viewpoint is moving.
I must admit, I hadn't even considered that brute force approach. I suppose it depends on the scene being rendered....small objects that don't cross the boundries between two frutums.
Anyway, I'm dragging this thread off topic, so I shall stop.

zed
05-05-2006, 03:39 AM
I'm not sure about this one any more. I know it was the case that the driver only exposed this on 5900 when it came out, but it appears to be showing up on 5600/5700 now.ta, im pretty sure it wasnt supported in my gf5200 ( i could check if necesaary)
also ive noticed FBO + mipmapped cubemaps dont seem to work. dont know if this is cause im doing it wrong or what.


The cheap card sitting in my current machine has 256mb of memory, and that's today....next year it will be even less of a problem.next year u will want 4096x4096 sized shadowmaps. also 3 frustums aint enuf, eg u will notice in the demo if youre on top of the hill looking out sometimes far away parts aint shadowed (thus can be solved with 4 frustums, but i figured the extra performance hit wasnt worth it)

anyways its not that much more rendering, its only meshes that straddle the boundry between 2 frustums that need to be rendered twice. so maybe an extra 20-40% rendering comapred to a single frustum.
but its not so back cause depth passes only are fast.
also spreadoing out the rendering over serveral frames is one of those ideas that sounds good until u try it, but u must update every frame or else its crap (unless maybe youre running at 100fps + updating every 2 frames ie 50hz maybes not to bad, but normally its very glaring to see an object + its shadow is outta sync). ive tried it before and it doesnt work visually (i now have the option in my game to spread the updating of the envmap over several frames and it looks not that great, and envmaps are much harder to notice than shadows)

zed
05-05-2006, 03:54 AM
btw what does nesting help, it only helps in instances where offscreen objects are casting there shadows into the scene. but even then theres places where it wont work eg sunlight 5 degrees above the horizon. eg so u have a tree a km away casting a shadow into the scene. u
could do a bias with the SM frustums if the sun is behind the viewer ( u have to sorta do this anyway, ie take the suns position relative to the camera dir into consideration when u decide what dir to focus the Sms on if u want optimal results)


small objects that don't cross the boundries between two frutums.aye!!?, a lot of objects will cross a frustum, esp for the nearer frustums where the overlap is great (~50%) u just have to render it in both frustums..
hmmm shall i go to the pub and watch the kiwis vs oz $10bet on nz for a win 12points less, return $47.50 (i think oz will win though)

knackered
05-05-2006, 08:21 AM
Well the idea, with the cascading approach, is that you don't have to update all the shadow maps every frame. Compare it to geometry clipmaps. If the viewpoint is moving slowly then you get plenty of time to update the highest detail shadowmap, but if the viewpoint is moving fast, you have plenty of low resolution shadowmap to tide you over until the high resolution one is rendered as the viewpoint slows down.
Read the geometry clipmaps paper to get an idea of how they could be adapted to shadowmaps.