im willing to write a wiki topic about the gffx + opengl, first off focusing on what it cant do
any others / corrections?
nows the time afore i commit this to paper
zed
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.
*No MRT
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
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?
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 
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
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.
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 something
IIRC 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 date
matethe 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
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.
“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”.
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.
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
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.
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
Ah, I’m dumb… I understood this to be discussing driver limitations as opposed to hardware limitations. Please ignore me. =)
Kevin B
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
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
// 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.
Your app crashes on my Nvidia 6800 (81.94 drivers)
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)
dont know about first
