Amithlon & GFX-cards: any advice?

[DrBombcrater]

@All

Just to clarify some points :

* There is no kernel support for the GeForce 6 series right now. I spent some time working on that but the GF6 family is just too different internally from the earlier GeForce parts. It needs a whole new driver, which I don't have time to write.

* The most modern cards supported at the moment are the GeForce FX series. The driver for these is fast and stable, although there are issues with some 'odd' FX cards (5100,5500 and some 5700s) not being picked up correctly. The driver has working DVI - at least on GF FX and GF4 cards.

If you have GF6 or GF7 card and replacing it is not an option I suggest fitting a GeForce FX PCI card and using a dual-input monitor or kvm switch to toggle between the two cards as needed.

* GeForce PCX (the PCI-Express versions of the FX series) should work, but I don't have one to test with.

* Actual dual-head functionality (ie, two independent screens) doesn't work.

* ATI cards work, at least the 7xxx, 8xxx and 9xxx families do. But the driver is buggy, slower than the GeForce one, and won't be developed any further. DVI is known to work on the 7000 and 7500, but seems to be broken on anything else.

At the moment what little development time I have is focused on getting the kernel working correctly with selected laptops. That's one area not really covered by anything else (bar UAE) and the gap is begging to be filled.

[DrBombcrater]

@humppa

Initial target is the GeForce-equipped members of the Acer Aspire 1360 series. The hardware in these is a good match for the kernel - so much that I have an unmodified 3.10 kernel running fine on a 1362 right now (I'm typing this on it now, and boy is it gorgeous :-D )

Almost everything works already.1280x800 hardware accelerated graphics, 100MB ethernet, audio, IDE DMA, etc. The default wireless card doesn't work, but it's a miniPCI card so its easy enough to replace with a compatible one.

The Apsire 1520 series is also a possible target, but a bit farther down the line. Those are more powerful than the 1360s (Athlon 64 & GF 5700 rather than the 1360's Sempron and GF5200) but they need modified drivers and seem to be much rarer than the 1360s.

[DrBombcrater]

@humppa

I'm no expert in this, but when assuming that all FX-cards can use the same kernel-driver for hw-acceleration (could be wrong on this), isn't it just a matter of adding all chip-IDs ("NV**") to the kernel?

If only it were that simple!

The NV3x series are not all exactly register compatible. The differences are subtle, but more than enough to break the driver. The biggest pain is that there is little predictability. When I got the driver working on the first generation FX cards (5200, 5600, 5800) I expected it not to work with the second generation cards (5700, 5900 and 5950) but in fact it worked fine on the 5900 and 5950, but broke horribly on some 5700s. Not all, just some of them.

Kernel 3.10 has the correct PCI ID for the 5500 so it will at least try to make it work.

[DrBombcrater]

@humppa

In any case it should work with Quadro-cards that are using the same chips as their Geforce-counterparts. Does Kernel 3.10 already have their PCI IDs? If not, would it help if I look them up for you (for adding them in a future version)?

The PCI ID list for 3.10 is mostly a direct pull from NVidia's Windows drivers (with known incompatible cards excluded) so Quadro cards should be picked up. No guarantees that they'll work, of course. I've never even seen a Quadro in the flesh.

On Amithlonopen I read that you were working on Voodoo3 support at some point, but only had a half-working beta version at that time. Any possibility for sending me that kernel? I'd really like to test...

That effort came to nothing when the last motherboard I have that can take an old AGP 2X card broke and took the Voodoo with it. The V3 is such a museum piece now that it seemed silly spending money to replace the boards, not to mention that development time is better spent on other things.

Stuff like support for modern AC97 codecs and Gigabit ethernet would probably still be unfinished had sufficient time been allocated to finish the Voodoo driver.  :-(

[DrBombcrater]

@humppa

Btw, I tried to extend beyond the standard VESA-settings, but none of my Setconfig settings (pixelclock, etc.) are picked up by Picasso96Mode.

The VESA system provides a set of pre-defined screenmodes. You can't alter those in any way, so any changes to parameters like the pixelclock are simply ignored. There's no way to fix this as it's a limitation of the way VESA works.

VESA is better than nothing but only just...

Changing the pixelclock and defining new modes requires a card that has specific driver support.

[DrBombcrater]

@Methuselas

What's the Ram limit on Amithlon now? Did you push it to 3GB, by chance, 'cos I'd like to max my ram slots, at least, if I can.

Ahh, that's a bit of a sore point. Because of the way Amithlon and the support kernel work it's not really possible for them to deal with more than 1GB of memory (and to make it worse any graphics card memory is mapped into that 1GB space, so '1GB' is probably about 700MB if you have a 256MB gfx card fitted).

But it's easy enough to tell the kernel to simply ignore any extra memory by using the 'mem=' parameter (ie, adding 'mem=512m' to the kernel boot string tells it to use only 512MB). I run Amithlon on a machine with 2GB ram and a 256MB gfx card using that method.

I had hoped to include a hack in the next kernel that boosted usable memory to 1.5GB, but testing has revealed this causes major incompatibilities on machines with crappy BIOSs (and there are lots of those) so it'll have to be pulled.

Also, I may be able to donate an older motherboard that supports 2X AGP, if you can get yourself another Voodoo. I'd like to get some sort of 3D accelration, one day.

I suspect the cost of sending a motherboard across the Atlantic would be rather more that its worth, but thanks for the offer  :-D

As for 3D, none of the kernel drivers will ever do that, period. The APIs in use are very basic and simply don't permit it. I've heard the tales about a working 68k Voodoo3 3D driver for Amithlon but I don't know anyone who's ever seen this mythical beast actually working.

[DrBombcrater]

@Shadowolf

Unfortunately my "WinFast A350 XT TDH" from LeadTek with FX5900 only gives me blinking keyboard LED's.

Flashing LEDs mean the kernel has crashed, which is almost always due to address space problems. Nothing to do with the gfx card at all.

There is 4GB of address space available on 32-bit processors (or 64-bit ones like the Athlon 64 when running in 32-bit mode). The Linux kernel splits that 4GB into 1GB kernel address space and 3GB user space.

On an Amithlon system your main RAM, plus any gfx card memory, plus some other bits and pieces, all has to be mapped into that 1GB kernel space. If that cannot be done the kernel will just give up and crash, causing flashing LED syndrome.

The cure, as humppa mentions, is to add 'mem=512m' to your kernel boot arguments. That instructs the kernel to ignore any memory past 512MB, leaving another 512MB of space available for the graphics card and other stuff.

[DrBombcrater]

@Ratte

Thanks for the clear statement,I asked many times on amithlon-open and didnt get any responce.

I don't read or reply on that list any more because too many people used it to demand I do things...

But ... hey ... i repeat my self and you got this bugreport last year ... and you promised a "bugfree" kernel for end 2006.

I know all about that bug, almost to the point of hating it. There is no 'bugfree' kernel because I have not been able to fix the bug, despite spending way too much time trying. If you check the mailing list archives you'll see that when talking about the next kernel I made it clear the Radeon pointer bug had not been fixed. That's still the case today.

To be honest, the Radeon driver was a bad mistake on my part. I've always tried to be clear that the purpose of the new kernel drivers is to make it easier to build or buy a PC that runs Amithlon well, while also being useful for other things. So the GeForce FX driver already made it possible to build an Amithlon machine that has good 3D support. Strictly speaking, the Radeon driver was then unnecessary but I released it anyway, on the assumption that Radeon owners would regard even a low-performance, buggy driver as being better than VESA mode. But the storm of complaints suggests I was wrong on that point. I apologise to anyone who exected a perfectly working driver.

Its up to you .. it s your time and your hobby.
But i am a little bit angry about this "late" statement.

Okay, let me spell out my position here:

My work on the kernel is done purely to help the Amiga community, as a way of enabling people to run AmigaOS when otherwise they might not be able to. The whole project is done on a 'best effort' basis - I just do what I can. By all means report bugs or ask for some specific bit of hardware to be supported, but don't get pissed off if the bug remains unfixed or the hardware unsupported.

I have very limited time to work on the kernel (further reduced by recent periods of ill heath) and the work itself is nightmarish. You try writing drivers for undocumented hardware that run on top of a ancient kernel and have to interface with an almost undocumented and abandoned closed-source emulator, which hosts an old and abandoned OS, all of which communicates via a set of closed-source pseudo-drivers who's inner workings are unknown to all but the one person who wrote them.

That the results are sometimes a little ragged is, I hope, excusable given those circumstances.

[DrBombcrater]

@Ratte

The RV350 pointerbug can be fixed by picasso96 settings (softsprite NON x86-p96-code)

No. That's not fixing the bug, just making it less obvious. The 'pointer bug' will cause errors any time lots of drawing operations are performed in a small area, so there are potentially lots of applications that could be affected.

Can I get the kernel-sources for debugging?

Yes. My snapshot of the 3.10 source seems to be broken, but I've uploaded a snapshot taken sometime between 3.00 and 3.10 here.

3.10 source will follow when I find out why it's not compiling anymore.

[DrBombcrater]

@Tenacious

Thanks to you, and the others who've commented, for the kind words. They're much appreciated.

The 1360 familiy is a few years old now, so it's not possible to buy them new. I doubt it's actually possible to buy any brand new laptop with GeForce FX graphics anymore. They do show up on Ebay from time to time.

But if you can find detailed specifications it's not that hard to tell if a laptop is suitable. It needs :

Processor: Single-core, preferably AMD, but Intel ones should be okay.
Chipset: VIA only.
Graphics: GeForce FX Go 5200, 5300, 5600 or 5700.
Ethernet: VIA Rhine II, VIA Velocity or Realtek 8139.
Audio: VIA VT1612, VT1616, or Realtek ALC6xx/ALC8xx.

[DrBombcrater]

@Ratte

Could you please send me an link for your latest ati kernel.

That's the most recent one I can give you right now, because it's the last working snapshot I have. The 3.10 snapshot is missing a whole bunch of files because the disk it's stored on seems to have filled up half-way through the copy process, and the copy script just failed silently :oops:

The kernel copy I'm working on right now has the experimental memory-map patch that fails on about 90% of systems, so it's pretty much useless until I get that picked out of the code.

And also a hint about your "forgotten" screenswitching testcode and where I can find it.

Sorry, I'm not sure what you're talking about. What screen switching code?

[DrBombcrater]

@humppa

Nice to hear you got it working  :-D

You had me worried for a moment there, because the DVI code has always worked on every FX card I've tried it on!

DVI auto-detect is broken on GeForce cards. This is listed as a known issue for 3.00, but also happens under 3.10 (and you are running 3.10, stupid me forgot to update the version string :oops:)

Edit: the kernel agruments stuff is a right pain in the bum. I spent hours wondering why the FX driver was giving me a screen full of random garbage on my laptop, it turns out I typed 'video=riva:640x480, flatpanel=1' instead of 'video=riva:640x480,flatpanel=1'.

Just adding one space caused the flatpanel argument to be ignored...

[DrBombcrater]

@Georg

I've tried grafting NV40-compatible loadstate routines into the rivafb driver (taken from the linux 2.6 nvidiafb driver, not AROS, however) without any success. Something is going wrong early in the initial card setup, and I've so far no idea what.

Are the AROS sources publically available? I've had a look but can't find them.