"Ask ATI" dev thread

[Svartalf]

I think the issue is that we don't have a link to the AGP hotfix driver on the main download page, so if you just follow the links you end up with a driver that doesn't include the AGP IDs.

I believe support for AGP under Windows will be in the next Catalyst driver -- if not then we should try to make the hotfix driver more visible.

I think that was the real point I was making...

[curaga]

So far I've seen usb sticks and wlan cards with the Penguin on the box.
Gigabyte's and Via's websites mention Linux right next to other supported OS's on their motherboards.

[Svartalf]

So far I've seen usb sticks and wlan cards with the Penguin on the box.
Gigabyte's and Via's websites mention Linux right next to other supported OS's on their motherboards.

Heh... Things are changing. I just looked at a batch of SanDisk thumb drives. Penguin was on the packaging, Having said this, the graphics card manufacturers and a raftload of others think that putting the Penguin on there means implicit support if it breaks. Give it time.

[givemesugarr]

Heh... Things are changing. I just looked at a batch of SanDisk thumb drives. Penguin was on the packaging, Having said this, the graphics card manufacturers and a raftload of others think that putting the Penguin on there means implicit support if it breaks. Give it time.

well, usr puts the penguin on their recent hw, gigabyte and via does enable support for it netgear releases routers with open source code and firware (this is awesome) but most of the producers will not put the penguin on the boxes since they'd be forced to prepare drivers for the products. on windows is simple since it is the same after some years, but on linux is more difficult since the drivers need to be tested with the ongoing kernels. selling penguin stuff without drivers to clients that aren't aware of how to make them work would be nonsense because they's lose customers.
so the problem with linux certification is this.

[Swoopy]

Isn't it so that once a driver for a certain piece of hardware is in the mainstream kernel, it's more or less supported automagically in Linux for the conceivable use-life of that piece of hardware (e.g. 3-5 years)?

So the challenge for hardware manufacturers isn?t that hard:
-develop hardware device (what they did anyway)

-release engineering spec. into OpenSource community

-assist the startup of the codebase that goes into the mainstream kernel

-monitor if new editions of the kernel don't break your code and pray to deity of choice that the kernel hardware device driver structure model doesn't get a major overhaul

-sit back and enjoy life being a hardware vendor who's stuff works in Linux !!

[bridgman]

If the programming model doesn't change from one model to the next that works, but for things like graphics cards with nearly 10,000 registers and frequent changes in core capabilities it doesn't work so well. Most of the driver (the part that has to keep changing) is outside the kernel, fortunately, so at least the kernel code (DRM) (no, not that DRM, the other DRM) doesn't have to keep spinning.

I don't know the exact numbers, but I would guess that >90% of the driver code for both open and closed source drivers is outside the kernel.

The main things we need IMO to get Tux on the box are (a) board vendors have to feel Linux market is important and have a Linux support policy in place (even if it's "no support"), and (b) Linux driver support needs to arrive on roughly the same schedule as Windows support so the board vendors can include Tux in the box graphics.

[Swoopy]

Once I typed out my "rule" and hit 'Post' I realised that graphics cards are THE exception to the "rule" because they typically don't get bundled up in the mainstream kernel.
So you are right in setting me straight, bridgman!

[bridgman]

Nobody wishes they were the same more than me. When I joined ATI I had been writing device drivers and working on graphics hardware for years, but I was totally blown away by the size of PC graphics drivers even back in the Rage Pro days.

"What, a million lines of code for a DRIVER ? Are you nuts ?"

Anyways, that was 10 years and millions of lines of code ago

[yoshi314]

is that clean code, or are there per-application performance [and other] hacks? :>

[bridgman]

Not much per-application, but a lot of general performance optimizations -- developed through testing individual applications -- which can get pretty complicated and make the code a lot bigger.

Making the chips draw triangles is pretty straightforward (I believe the current 3d open source driver is about 15k lines, although mesa itself is obviously a lot bigger), but taking full advantage of all the performance enhancements in the chips makes the driver *way* more complicated. Workstation apps often behave quite differently from consumer apps and need different code paths for best results.

Since we don't use the mesa stack in our closed driver we need the full GL implementation, not just the ASIC-specific bits, so that adds a lot of code as well.

Then again, as big as our driver stack may be I guess it's still a good bit smaller than (X + mesa + X driver + DRM + mesa driver) -- not a fair comparison because X includes input and window functions, but not all that unfair either.