Discussion in 'RivaTuner Advanced Discussion forum' started by gellmar, Oct 3, 2008.
Be patient, I am trying to DEBUGGGGGGGGGG it!:biggun:
DELL 8_453_1_6 drivers.
btw, Schloko's patch works with CCC as far as I can tell. Of course the drivers and Maya have their own problems, such as overlay corruption in 10bit mode. So if anything can be made to work better, I'm all for it!
This just occured to me: when using your x64 script, I inserted my HW ID (670 = 9501 = 01 95) string in the appropriate place as per Schloko's script.
Now, Looking at your script, you seem to be forcing the drivers to see the desired chipset of the FireGL card. Such as forcing detection of a 9511. Which is a different strategy from Schloko, who forces the drivers to see the Radeon ID as an OpenGL card....
Also, does the .inf need to be edited to replace the FireGL ID with Radeon ID, as per Schloko's patch? (i.e. 9511 to 9501)
If you can hack the 8.5xx drivers, awesome. Will continue following this thread and beta-test. Will also try this patch script again with DELL's .6 drivers.
Update, just tested Gellmar's x64 script again with DELL 8.453.1.6 drivers on my 3870, and it passed SpecMaya accelerated like a v7700. (scored ~250) My earlier mistake was inserting my device ID as per Schloko's script.
The correct way to use Gellmar's script is *AS IS.* Do not edit it at all. Do not edit the .inf either.
UPDATE: some wile ago I reverted to using Schloko's patch script, which for whatever reason (could be luck) I've had less stability issues with.
I'm currently using Schloko's script for 8.453.1.6
Hope somebody can crack x64 drivers above that, someday!!!
well done, gellmar and samiam!!
Did you change the inf from 9511 to 9501 ?
Well, I've tested the 8.5xx drivers once again, since I as well assumed I had to adapt the .INF deviceID. After not-doing that again, I installed the 8.5xx driver and rebooted. The system was unable to get out of 640x480x8bit mode however, and after each reboot (I used some ellbow-grease to try to get it to work), it kept saying "the system has recovered from a serious error".
So no luck on the 8.5xx yet, but I guess Gellmar, our soon-to-be-hero, is still debugging .
Very nice development though. I'm up for beta testing, as you might have noticed.
No, I left both the .inf and the script unchanged.
I notice that the HW manager still sees my card as HW ID 9501. However, CCC and all the driver based control panels see it as a 9511.
On 8.453.1.6 , I had to change the inf file.
When I manually pointed to the driver inf location, it could not find my card, so I had to add 9501 to the file as R630GL.
Then the driver worked as good as schoko 8.453.1.3 mod.
However it did not work with 8.523.1.1 driver; only ugnx-01 test showed workstation card performance, the other tests had radeon performance.
Why would I investigate a thread that hasn't been posted in, in 7 months? With the last post being some one saying they got it working on a 3XXX based card. Obviously that thread doesn't have the latest drivers supported in it.
I also made a thread http://forums.guru3d.com/showthread.php?t=273159 asking about any updates for HD2XXX hardware that got not one single response.
I'm sure theres still plenty of people out there on HD2XXX hardware who would like to see an update.
Also the title of this thread doesn't specify HD3XXX based cards, it says " XP32 and XP64 patchscript for FireGL and FirePRO (driver 8.44 and higher)"
So point to me in the title where it specifies only HD3XXX cards please.
johnpv, you are correct, it CAN be used for 2XXX but you will have to add a string with your desired DevID if you wanna to.
Folks, some interesting chewing gum for your brain after three days of an intensive debug!
After short-dealing with WinDBG x64 for three days, I have noticed the following:
1. The schoko's scripts and ones of mine patched the procedure of runtime security check for VenID forcing - it sems to be checked each time so NOPped jumps from schoko win about average 1 fps on my tests.
2. The other patches were referred to the set of bit $2E in the device bitmask in two other places (like the routine in claim 1 did). There were 5 points where this bit was either set or unset, I tried patching them all - still no luck. (EDIT: 5 points to set, how many to unset - it's a great idea to thinnk around!)
3. I tried to check the driver from 8.523.1 with 8.453.1 roundup (i.e OGL render etc) to ensure the additional protection is not located somewhere outside the driver - it worked but the results were the same. The 8.453.1 drv with 8.523.1 roundup made me a display crash (lucky without BSoD).
4. the driver has lot of new code, however all the patched routines and its background seems to be unchanged comparing to 8.453.1.
So, any ideas on where is a prot?
schoko had an idea on that.
On a previous thread dating a few months, he explainde that there was another protection on a new file ATI introduced, and therefore the patch was not working on 8.502. do not remember which thread it was or when it was.
He should have time to look at the new driver; as far as I remember he hinted that the first time he would be able to look at the driver was last week.
It is a good idea to consider 8.502 drivers, cause lots of newly-added code in 8.523.1 seems to be used with FirePRO's. So, it is very hard to reveal whether the specified code relates to the protection or to the new features.
For example, I found the new condition for setting the $BA device bitmask bit relative to 8.453.1. I tried to force it as it was in 8.453.1 and... got a fast BSOD So, I have the following questions now (maybe somebody of the Gurus will help me with them):
1. The DeviceID is revealed from HW_DEVICE_EXTENSION structure, and the script fixes its redefinition. So,the question is - how can the driver get the DeviceID without HW_DEVICE_EXTENSION (I have found that it can be done directly using DeviceID PCIE register of ATI GPU, but how can it be achieved via VideoPortReadRegisterUlong I still don't understand)?
2. The set $2E bit probably indicates pro capabilities enabled (cause it is used in all schoko's patched entries). However, the 10bit and stereo quad buffers rely on other PCIE registers that are documented in ATI RV630 Register Programming Manual - and in the code of miniport driver there seem to be NO signs of that calls. So, the question is - how can the separate register be accessed and how to calculate the parameter of the bitset procedure which is responsible for that register settings?
3. What else can be used as Radeon vs FireGL identification except DevID and some bitmasks (i.e the fact that something was ADDED blocking FGL blocks usage on the same card as with 8.453.1)
4. A personal question to Schoko, if he reads this post - schoko, if you know exactly what type of protection do that ATI guys use, why can't you defeat it? It seems to be very doubtful you had no time (even an hour) during all that month and a half since your last official post. And I am sure you are reading it cause you have been on the forums yesterday 11.27))
this are the id for 3870 and equivalent of firegl 3870 actually 9710 firestream and 3850 is 7700 according to wikipedia
I tried installing with and without device id change and corrupted my windows really bad
not sure what to do
I will try once again so after all do you say we should only patch ati2mtag then makecab it or should we change the firegl id to radeon id
I am really confused after reinstalling windows several times
A yet another seem-to-be-protection found in 8.502 against 8.453!
Folks, seems I found something interesting!
I looked inside the 8.502 driver set and understood the following:
1. They introduced new user-mode library called atiadlxx.dll which was absent in 8.453. It has user-mode routines checking the DeviceID and capabilities of monitors and adapters using ExtEscape function. (EDIT: The library belongs to ADL, but I still can't check if it returns 9505 or 9511 as DevID)
2. In the driver itself, I have found the second instance of a call very similar to the call in the protection routine. However, the procedure was not the same but the calling arguments seem to be identical. So, I assume that is a kind of a new protection we supposed to be introduced. I tried forcing the result of the newly-discovered routine to either 0 and 1, but it still does not affect the softmod speed. But, the piece of code seems to be very interesting, and now I continue with the piece one call above with eax =0 check and sequential setting some registers I haven't patched yet.
So, can this library (from the claim 1) get a DeviceID not from miniport? And the capabilities flags routine's output is fixed (i.e no subsequent calls are made to reveal them). What can it be - either a monitoring tool or a protection?
(EDIT: it uses ExtEscape function with specific codes that can be revealed from atidemgx assembly - the new DEMG refers to ADL, but ADL is still not used there)
does anyone have the same problem as me? (solidworks and winxp64 related)
We bought two high end workstations for modelling with exact spects. Quad core 8GB ram, and Saphire 3870.
Since I had some experience with this patch, I thought would be the best to save some money...
I did manage to modify the ati 3870 to fire gl 7700 and all seem to work fine. We work both with alias studio tools and Solidworks, plus sometimes ProE and Max.
First issue is that Im not able to access the pro settings....but with SpecViewperf10 it all seems to get pro performance.
The previous 3d soft seem to work fine but somehow there is a big bug with solidworks. I thought that it would be the 2008 version but I just installed the new 64bit 2009 version and still has the same problem. It just freezes the computer after 3 seconds of just modelling anything.
I suspected there was something wrong with the drivers. (8.453.1) firegl 7700
I just installed the new ati drivers from the radeon series... and all works fine but ofcourse without Pro capabilities.
anyone with a solution???
I have XP64, 3870-->7700, 4GB and have no problem with 8.453.1.3 at all.
Same here, XP64, 3870 using 8.453. No problems (except for a broken vidcard, but it is on its way back to the manufacturer(not patch related)).
Have a 4670 on temporary basis, so I could test the mods at some point, although I've moved back to vista for a while, just to tax the machine.
Urrrrrgggh, that was not the protection!
So I revealed that was ADL and it was not the protection