So we can assume you have Win64 & and AMD64? Because these are the only 51.xx drivers that have been “officially” released - and even that as a Beta only…
Originally posted by rgpc: So we can assume you have Win64 & and AMD64? Because these are the only 51.xx drivers that have been “officially” released - and even that as a Beta only…
Are we on a dev forum or what? Beta/unofficial drivers have always been used by developers as they usually contain fixes for known bugs, which helps developers to move on. Nobody here will ever complain about experimental/early implementation of new stuff like shader objects not being rock stable in a beta.
Getting feedback is good for IHVs, as shown by the presence of some of their employees on this board. I fail to see the problem of discussing problems/changes in a new driver release, even if it’s a beta.
Thanks cass but I do not have problems. I said that there was a bug so that people would be aware of that. I know they’re beta, but normally here that doesn’t matter much. Anyways, the bug is somewhere in the sync. If I do not uptade a buffer, it’s fine, if I change the data dynamically I get weird results. But you are probably aware of this…
I guess there is probably a lot of people waiting for the shader objects, and maybe they could do something with them with these driver set. Like what happened with vertex_buffer_object. They were not on the extension string, but we could use them anyway…
“cass, is there something we should know about?”
I was expecting an answer like: “Yes, you can mess with glSLang with these drivers. There are still bugs, but you can use it”
So we can assume you have Win64 & and AMD64?
…
[This message has been edited by KRONOS (edited 09-16-2003).]
Originally posted by kehziah:
Beta/unofficial drivers have always been used by developers as they usually contain fixes for known bugs, which helps developers to move on. Nobody here will ever complain about experimental/early implementation of new stuff like shader objects not being rock stable in a beta.
Obviously someone has complained about a Beta release. But the list of released beta drivers only included one 51.xx driver (and now one 52.xx) and that was a Win64/AMD64 driver.
That aside, this isn’t the forum for complaining about the problems in a Beta/Leaked version of drivers.
From 3dChipset.comI want to say thanks to the folks who are mirroring these files we leaked. Thanks goes to viper at Tech Connect, [AIX]Hood at File Rush, Nazgul on his server, and AzraeL Tek Xtreme for helping mirroring the WinXP & Win2k Beta 51.75 Detonator driver. Hats off to you fella’s for contributing…
Well, I I like the interface & adittional features of 50, seems that OC auto detect isn’t working. Performance has increased in all apps from 15-30%, I’ll try to check IQ today Didn’t had time to check my own apps though.
image filter in this example implemented with glAccum, but with 51.75 it’s not work.
2Zengar
hidden extensions(nv34)
NV_fragment_program2
NV_vertex_program3
NV_program_registers
>>never heard of it…
Not only you. Nevertheless this strings coexist inside nvoglnt.dll together with NV_fragment_program & NV_vertex_program/2.
accconvolve uses a single-buffered window. The rendering doesn’t appear because it never calls flush. If you add a flush after glAccum(GL_RETURN), the app should work correctly (it does for me).
It worked in software because software doesn’t batch any commands.
Didn’t had time to check my own apps though.
Nevertheless this strings coexist inside nvoglnt.dll together with NV_fragment_program & NV_vertex_program/2.