View Full Version : To be included in Catalyst 5.11: 'Miracle' OpenGL hack
I was browsing the Inq and came across this little tidbit of info:
http://www.theinquirer.net/?article=26946
Looks promising. There may be life in my old 9700 Pro yet! :D
Sentential
10-15-05, 01:09 AM
This is great news. Its about time they fied their OpenGL support
TollhouseFrank
10-15-05, 02:22 AM
WOW. that's a HUGE increase just from a 'little hack'.
and ATI just NOW discovered this? sounds fishy. Sorta like they were holdin' back all along, but that's just conspiracy theory talkin' there.
I wonder if NVIDIA can pull off some sorta 'miracle hack' like this
chr0nicles
10-15-05, 08:55 AM
i love hacks :santa:
james.miller
10-15-05, 11:24 AM
as far as im aware its only for the x18xx series. those with the programable memory controllers, so dont get your hopes up yet guys.
Quailane
10-15-05, 12:45 PM
There may be life in my old 9700 Pro yet! :D
Doesn't help a 9700.
Vipasnipa
10-15-05, 04:44 PM
And what about the X8x00 series?
vulcanman09
10-15-05, 07:35 PM
actually if read carefully
it states that the hack changes the way the gpu accesses
the onboard memory chips
it does not state that it is exclusive to the 1800 series
video cards
imagine what a 9700 pro can do with the hack
james.miller
10-16-05, 10:50 AM
Raja Koduri, one of the key engineers at ATI, and his team working on programmable memory controllers developed a little tweak that can result in a significant performance increase.
reading it carefully would suggest this only apply to cards with probrammable memory controllers.......the x18xx's. maybe that's reading too carefully? who knows, but we'll find out soon.
Quailane
10-16-05, 01:06 PM
actually if read carefully
it states that the hack changes the way the gpu accesses
the onboard memory chips
it does not state that it is exclusive to the 1800 series
video cards
imagine what a 9700 pro can do with the hack
Actually if read more carefully, it is exclusive to cards with programmable memory controller.
n0irsmurf
10-16-05, 01:09 PM
Actually if read more carefully, it is exclusive to cards with programmable memory controller.
But if you read EVEN more carefully, you'll find a hidden message. :bang head
Quailane
10-16-05, 01:12 PM
You should take a look at this article too:
http://www.hexus.net/content/item.php?item=3668
It is a lot more realistic than the inquirer article is.
could they possibly just be utilizing the extra 256 of memory ?
I mean thats what its there for isnt it ?
They have to make a driver for it optimize the new cards, seems like a normal course of action not a hack or some kind of UBER discovery....
Schalldampfer
10-16-05, 01:19 PM
I just find it funny that there's an option to flame the author in the Inquirer.
Quailane
10-16-05, 01:19 PM
could they possibly just be utilizing the extra 256 of memory ?
I mean thats what its there for isnt it ?
They have to make a driver for it optimize the new cards, seems like a normal course of action not a hack or some kind of UBER discovery....
Well, since you are too lazy to read the article :rolleyes:
Our new MC has a view of all the requests for all the clients over time. The "longer" the time view, the greater the latency the clients see but the higher the BW is (due to more efficient requests re-ordering). The MC also looks at the DRAM activity and settings, and since it can "look" into the future for all clients, it can be told different algorithms and parameters to help it decide how to best make use of the available BW.
As well, the MC gets direct feedback from all clients as to their "urgency" level (which refers to different things for different client, but, simplifying, tells the MC how well they are doing and how much they need their data back), and adjusts things dynamically (following programmed algorithms) to deal with this. Get feedback from the DRAM interface to see how well it's doing too.
We are able to download new parameters and new programs to tell the MC how to service the requests, which clients's urgency is more important, basically how to arbitrate between over 50 clients to the dram requests. The amount of programming available is very high, and it will take us some time to tune things.
In fact, we can see that per application (or groups of applications), we might want different algorithms and parameters. We can change these all in the driver updates. The idea is that we, generally, want to maximize BW from the DRAM and maximize shader usage. If we find an app that does not do that, we can change things. You can imagine that AA, for example, changes significantly the pattern of access and the type of requests that the different clients make (for example, Z requests jump up drastically, so do rops). We need to re-tune for different configs. In this case, the OGL was just not tuning AA performance well at all. We did a simple fix (it's just a registry change) to improve this significantly. In future drivers, we will do a much more proper job.
again its the utilization of the new tech, more ram and the 512 ring bus :rolleyes:
Quailane
10-16-05, 02:12 PM
again its the utilization of the new tech, more ram and the 512 ring bus :rolleyes:
Yeah, but it has nothing to do with the extra memory.
It is just an increase in the efficiency of memory controller. Very similar to native comand queing, except that this is actually fast enough to gain an advantage from it.
either way I wanna play with a X1800XT :p
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.