Jump to content

New AGPGart


  • Please log in to reply
940 replies to this topic

#261
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts
@ bimmer

It doesn't seem we can make it work for Intel atm but there is hope I think, the problem is absolutely in AGPGart and not in IOPCIFamily, at least in the case of Tiger.

It's strange that I get it to work in Tiger (running 10.4.11 now) but in leopard I get an error message from the nvidia driver. The funny thing is that you get the same error in Tiger as I get in Leopard but somehow Tiger works for me.

My guess is that we reach the same problem through different actions, your AGPGart is not working well so it screws up memory addressing or something, and for me Leopard screws up memory addressing and therefore we get the same problem but the cause of the problem is different.

#262
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@ common sense

I tried AGP 2.1 with PCI 2.2 again, i now make it to the blue screen before the login window, i was able remote in, and get the dmesg. Here they are. What are you using to get your Nvidia card working? (ie.. NVInject, Natit, Titan?????)

Edit:

Here are my files from single user mode.

Attached Files



#263
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts

@ common sense

I tried AGP 2.1 with PCI 2.2 again, i now make it to the blue screen before the login window, i was able remote in, and get the dmesg. Here they are. What are you using to get your Nvidia card working? (ie.. NVInject, Natit, Titan?????)

Edit:

Here are my files from single user mode.


Im using the same version of NVInject as you do. Please try my modified version of AGPGart 2.62. Use IOPCIFamily 2.2 for the test.

Thanks!

Attached Files



#264
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@common sense

You are moving in the right direction, i made it to the blue screen before login window. Here are my dmesg from single user mode and remote login.

Attached Files



#265
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@common sense

sorry, but i'm going to gone for the next 6 hours, i will continue testing when i get back.

#266
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts

@common sense

sorry, but i'm going to gone for the next 6 hours, i will continue testing when i get back.


No problem Bimmer I need to do some school work now anyway.

#267
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@common sense

I'm back, did you see anything from the dmesg?

#268
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@common sense or slice

Here is my dmesg from Leopard (10.5.2). I made it alittle further than Tiger. I got to the blue screen before login, than it faded to black and gave me my mouse cursor, which i could move around. I used AGPGart 2.6.2, and stock IOPCIFamily 2.4.1.

Attached Files



#269
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
Here is dmesg using IOPCIFamily 2.4.3. Same result as above.

Attached Files



#270
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,074 posts
  • Gender:Male
  • Location:Moscow

It doesn't seem we can make it work for Intel atm but there is hope I think, the problem is absolutely in AGPGart and not in IOPCIFamily, at least in the case of Tiger.

It's strange that I get it to work in Tiger (running 10.4.11 now) but in leopard I get an error message from the nvidia driver. The funny thing is that you get the same error in Tiger as I get in Leopard but somehow Tiger works for me.

My guess is that we reach the same problem through different actions, your AGPGart is not working well so it screws up memory addressing or something, and for me Leopard screws up memory addressing and therefore we get the same problem but the cause of the problem is different.

What I found.
With old IOPCIFamily
AGPINTEL trace PCI space
(00)=25708086   (04)=20900006   (08)=06000002   (0c)=00000000   
(10)=f0000008   (14)=00000000   (18)=00000000   (1c)=00000000
(10) - AGP_APER_BASE
With new one
AGPINTEL trace PCI space
(00)=25788086   (04)=20900006   (08)=06000002   (0c)=00000000   
(10)=00000008   (14)=00000000   (18)=00000000   (1c)=00000000
See the difference!

I don't know is it a difference Tiger 2.2<->Leo 2.4 or it is my correction 2.4<->2.4.x because 2.4 don't work for me.
I want you make such traces of host controller (dev=0 func=0) and hammer (dev=24 func=3) and compare two cases:
1. Working situation in Tiger
2. Black screen in Leo

I also check that
//Slice
	err = getDTNubAddressing( nub );  //V22
//	err = getNubAddressing( nub );  //V16
result in non-working PCCard, so I return back to getNub as in IOPCIFamily 2.4.2 (v16)

NEXT

#271
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@Slice

Is this for Common Sense or me? If it is me, I'm not sure what you want me to do. I see the difference. Just give me a little me instruction on what you want.

#272
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts

What I found.
With old IOPCIFamily

AGPINTEL trace PCI space
	(00)=25708086   (04)=20900006   (08)=06000002   (0c)=00000000   
	(10)=f0000008   (14)=00000000   (18)=00000000   (1c)=00000000
(10) - AGP_APER_BASE
With new one
AGPINTEL trace PCI space
	(00)=25788086   (04)=20900006   (08)=06000002   (0c)=00000000   
	(10)=00000008   (14)=00000000   (18)=00000000   (1c)=00000000
See the difference!

I don't know is it a difference Tiger 2.2<->Leo 2.4 or it is my correction 2.4<->2.4.x because 2.4 don't work for me.
I want you make such traces of host controller (dev=0 func=0) and hammer (dev=24 func=3) and compare two cases:
1. Working situation in Tiger
2. Black screen in Leo

I also check that
//Slice
		err = getDTNubAddressing( nub );  //V22
	//	err = getNubAddressing( nub );  //V16
Give me non-working PCCard, so I return back to getNub as in IOPCIFamily 2.4.2 (v16)


You do remember that you have changed the deviceNum to 1 in amd64.cpp? Anyway for the debugging im reading from dev=0 and func=0 as you wanted just checking if that is correct or if you forgot that you changed deviceNum to 1.

Im attaching the zip file as usual, let us know what you find!

EDIT: I just compared the Tiger 2.4.3 and Tiger 2.2 and noticed a difference so I decided to do a second try with Tiger and 2.2 just to verify that the result would again be the same as before.

The result differed!! so even when using Tiger and IOPCIFamily 2.2 the results are going to differ from reboots! But yet AGP always works so its going to be hard to draw any conclusions from these values since if they change across reboots with the same setup how could we draw conclusions when we compare these results?

EDIT2: The results differ for both hammer and host controll (across reboots with the same version of IOPCIFamily as stated above)

Attached Files



#273
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts

@Slice

Is this for Common Sense or me? If it is me, I'm not sure what you want me to do. I see the difference. Just give me a little me instruction on what you want.


It must be for me since he talks about hammer and that applies only to AMD systems. He quotes some Intel results in another later post are those from your machine?

#274
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@common sense

in post 270, i noticed the AGPIntel Trace, that's why i wasn't sure. Did you see anything from my dmesg or ioreg?

#275
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,074 posts
  • Gender:Male
  • Location:Moscow
First of all thank you for detailed testing!

You do remember that you have changed the deviceNum to 1 in amd64.cpp? Anyway for the debugging im reading from dev=0 and func=0 as you wanted just checking if that is correct or if you forgot that you changed deviceNum to 1.

You didn't understand me
via.s.deviceNum = 1; -- this is previous codes. It is wrong because real device
| | +-o VIAN@0 <class IOPCIDevice, registered, matched, active, busy 0, retain 6>
Real VIA host controller Dev=0 -- right value

Im attaching the zip file as usual, let us know what you find!

EDIT: I just compared the Tiger 2.4.3 and Tiger 2.2 and noticed a difference so I decided to do a second try with Tiger and 2.2 just to verify that the result would again be the same as before.

The result differed!! so even when using Tiger and IOPCIFamily 2.2 the results are going to differ from reboots! But yet AGP always works so its going to be hard to draw any conclusions from these values since if they change across reboots with the same setup how could we draw conclusions when we compare these results?

EDIT2: The results differ for both hammer and host controll (across reboots with the same version of IOPCIFamily as stated above)

It is real problem to find why PCI bus different from reboots. Some unintialized values in IOPCIFamily?
I, for example, have a different OpenGL memory size from reboots.
But my previous question about (10) you resolve. For you it is always 0.

This value (98)=00058d40 is always different because it is IOMalloc result. Random address.

The real difference in hammer
243 for tiger
(50)=0fc29778   (5c)=fd9be7c0	 (e4)=08670020
243 for leo
(50)=00000000  (5c)=fd9befc0	 (e4)=08630020
I have no description of these places ;)
Probably for Leo AMD works in other mode?

2 Bimmer
I have no yet any comment s for you.

#276
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts

@common sense

in post 270, i noticed the AGPIntel Trace, that's why i wasn't sure. Did you see anything from my dmesg or ioreg?


It looks good, anyway for Tiger the specific Intel code in AGPGart needs to be rewritten and once its correct it will work. Leopard is a different story.

#277
Bimmer

Bimmer

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 111 posts
@ Common Sense and Slice

I'll be standing by, what ever you guys need, let me know.

#278
Common Sense

Common Sense

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 226 posts
@ Slice

This is probably not very important but I noticed differences between IOPCIFamily 2.4.3 and 2.2 on Tiger and 2.4.3 and 2.4 on Leopard.

The difference is the same for both Leopard and Tiger so its related to your IOPCIFamily 2.4.3.When booting single user I manage to get some information that is being "pushed out" later in the boot process, here is my find:

dmesg:2.4.3 (Both Tiger and Leopard)

DEBUG fixing subordinate bus setting on P0P1 device(1, 0) - was 1 now 255
AGP: Found VIA AGP bridge for AMD
AGPBridge buses: pri 0 secBus 1 subBus 255 BridgeDev 0
AGPGart subBus corrected
AGPgart: BridgeMemoryRange [f9f00000, fbffffff]
AGPgart: BridgePrefetchableMemoryRange [f0000000, f8ffffff]
AGPgart: BridgeIORange [0000f000, 00000fff]
AGP: saveBridgeState OK
AGP create nub for 004210de bus=1 cap=68
AGPGart: publishNub display

2.2 or 2.4 (2.2 in Tiger and 2.4 in Leopard)

AGP: Found VIA AGP bridge for AMD
AGPBridge buses: pri 0 secBus 1 subBus 1 BridgeDev 0
AGPgart: BridgeMemoryRange [f9f00000, fbffffff]
AGPgart: BridgePrefetchableMemoryRange [f0000000, f8ffffff]
AGPgart: BridgeIORange [0000f000, 00000fff]
AGP: saveBridgeState OK
AGP create nub for 004210de bus=1 cap=68
AGPGart: publishNub display

I'm sending the dmesg outputs zipped.


@ Common Sense and SliceI'll be standing by, what ever you guys need, let me know.



Thanks! I'm also ready to do some testing, just don't know what to test next :P

I'm starting to get a feeling that the Leopard problem lies in the ACPI classes and that can spell trouble as there are no sources for them, some user on another forum suggested graphics drivers and if it's in there the problem occurs we are screwed.

On the other hand PowerPC works with AGP in Leopard but perhaps the ACPI classes implement something different for PowerPC and Intel? Perhaps its the kernel thats to blame?

@ Slice

What do you think is the problem if you were to take a guess?

Attached Files



#279
Beerkex'd

Beerkex'd

    Content Provider

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 3,000 posts
  • Gender:Male
  • Location:Belo Horizonte - Brazil
I've been following this thread with great interest.
If there's anything I can do to help, please let me know.

I have full acceleration but my card is recognized as PCI.

Performance seems good in the Quake 4 and Tomb Raider Anniversay demos - but at 640x480.
At 1024x768 and above I get massive slowdowns.

I'm a little bit scared of using the terminal but if it's for the greater good I think I can do it. :thumbsup_anim:

#280
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,074 posts
  • Gender:Male
  • Location:Moscow

This is probably not very important but I noticed differences between IOPCIFamily 2.4.3 and 2.2 on Tiger and 2.4.3 and 2.4 on Leopard.

The difference is the same for both Leopard and Tiger so its related to your IOPCIFamily 2.4.3.When booting single user I manage to get some information that is being "pushed out" later in the boot process, here is my find:

dmesg:2.4.3 (Both Tiger and Leopard)

DEBUG fixing subordinate bus setting on P0P1 device(1, 0) - was 1 now 255
AGP: Found VIA AGP bridge for AMD
AGPBridge buses: pri 0 secBus 1 subBus 255 BridgeDev 0
AGPGart subBus corrected
AGPgart: BridgeMemoryRange [f9f00000, fbffffff]
AGPgart: BridgePrefetchableMemoryRange [f0000000, f8ffffff]
AGPgart: BridgeIORange [0000f000, 00000fff]
AGP: saveBridgeState OK
AGP create nub for 004210de bus=1 cap=68
AGPGart: publishNub display

2.2 or 2.4 (2.2 in Tiger and 2.4 in Leopard)

AGP: Found VIA AGP bridge for AMD
AGPBridge buses: pri 0 secBus 1 subBus 1 BridgeDev 0
AGPgart: BridgeMemoryRange [f9f00000, fbffffff]
AGPgart: BridgePrefetchableMemoryRange [f0000000, f8ffffff]
AGPgart: BridgeIORange [0000f000, 00000fff]
AGP: saveBridgeState OK
AGP create nub for 004210de bus=1 cap=68
AGPGart: publishNub display

I already corrected back subbus to 1, else AGP don't work. It was main problem why AGPGart 260 doesn't work with my or Chun-Nan IOPCIFamily

I'm sending the dmesg outputs zipped.
Thanks! I'm also ready to do some testing, just don't know what to test next :)
I'm starting to get a feeling that the Leopard problem lies in the ACPI classes and that can spell trouble as there are no sources for them, some user on another forum suggested graphics drivers and if it's in there the problem occurs we are screwed.
On the other hand PowerPC works with AGP in Leopard but perhaps the ACPI classes implement something different for PowerPC and Intel? Perhaps its the kernel thats to blame?
What do you think is the problem if you were to take a guess?

I show you in previous post that hammer (AMD) tracing differ in Tiger and Leo. We have no access to AppleACPIPCI but we can correct the situation inside AGPGart. How? I think it is a task for you: look for AMD documentation about memory controller in AMD64 CPU. I have only Intel CPUs and can't make any experiments.

I've been following this thread with great interest.
If there's anything I can do to help, please let me know.
I have full acceleration but my card is recognized as PCI.
Performance seems good in the Quake 4 and Tomb Raider Anniversay demos - but at 640x480.
At 1024x768 and above I get massive slowdowns.
I'm a little bit scared of using the terminal but if it's for the greater good I think I can do it. :(

There is no place for teach a novice. Please read FAQs and the Topic.
If you are successful in pci mode it is interesting to see your tests in AGP mode. So try please AGPGart. If you can work in AGP mode run XBench and GioFX OpenMark. Both are free program.

2 toadspit
I found a crash for you. With this version you might be more successful.

4 All
These versions contain all corrections that I previously mention and useful traces. Try again!


NEXT

Attached Files







0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy