Opensource 4770 support?

[ernstp]

Hi,

anyone seen or heard anything about opensource 4770 support?

[bridgman]

Most people are reporting that if you add the IDs then "it works", but some are having problems. The display controller didn't change much but IIRC there were some changes in the memory controller. You probably need to map the 4770 to rv770 when adding IDs to the existing driver but not 100% sure -- we have boards on order and should be able to do more testing next week.

I think agd5f might have more details; people usually call him, not me, when getting a new board working :D

[chithanh]

According to http://www.phoronix.com/scan.php?page=news_item&px=NzI1MQ it is not sufficient to add the PCI IDs to the open source drivers.

[bridgman]

According to http://www.phoronix.com/scan.php?page=news_item&px=NzI1MQ it is not sufficient to add the PCI IDs to the open source drivers.

Yeah, apparently it was working for some people but not for others. That's what I was told anyways; we'll know more next week.

[agd5f]

The cards are DCE 3.2 based so you'll want to treat them like more like rv730 cards rather than rv770 from a display perspective. This patch adds the ids properly, I don't have the hardware yet to test yet:
http://www.botchco.com/alex/xorg/rv740.diff

[gsacks]

-- we have boards on order and should be able to do more testing next week.

Seriously???? I'm confused. The driver team for AMD/ATI has 'boards on order' for a new product that is already on the market. Shouldn't you have had them for in house development and testing BEFORE they hit the market? I mean, if there is any single group of people who should have early access to the hardware, it is the driver developers. That is just dumbfounding.

[bridgman]

Sure, we have engineering samples in house for development and testing and have had them for a while. Engineering samples, not final boards with final settings and final BIOS images. AMD has a lot of offices and not all of them do driver development; agd5f doesn't happen to work in an office where we would have engineering boards.

Once development has finished we replace most of the engineering samples with production boards anyways, so that ongoing development and testing can happen on the same boards you see. I could probably score some engineering sample boards and save a few days but that still wouldn't get final production SKUs into our developers hands.

The proprietary drivers essentially go through at least two passes, once with engineering sample hardware and again with final production hardware. For the open source drivers we normally wait until final hardware is available.

The driver devs have access to the hardware on room-sized hardware emulators long before we even have first silicon.

[gsacks]

Sure, we have engineering samples in house for development and testing and have had them for a while. Engineering samples, not final boards with final settings and final BIOS images. AMD has a lot of offices and not all of them do driver development; agd5f doesn't happen to work in an office where we would have engineering boards....

Fair enough. Thanks for the explanation. The original statement just made it seem like you were working from nothing but specs. Which was hard to believe. (And clearly, not the case).

[ernstp]

Any updates on this?

[bridgman]

Production boards should have been in this week but didn't show up.

Alex has pinged purchasing to find out what the holdup is. Worst case we'll see if the of the driver teams can free up an engineering board so we can ship that to Alex.

[droidix]

I noticed that this commit added support for the 4770 to the radeon driver:

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=7599dc40855c33a5fbd8e9bbc2b4cd62752fb7df

These changes look pretty minor, do you think those same changes could be applied to the 6.12 branch? The reason I ask is that I am pretty sure Fedora uses the 6.12 branch and I would like to get my 4770 working in Leonidas.

[Kano]

I would not think too complicated, just use normal git clone and compile. Should do.

[agd5f]

I noticed that this commit added support for the 4770 to the radeon driver:

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=7599dc40855c33a5fbd8e9bbc2b4cd62752fb7df

These changes look pretty minor, do you think those same changes could be applied to the 6.12 branch? The reason I ask is that I am pretty sure Fedora uses the 6.12 branch and I would like to get my 4770 working in Leonidas.

I plan to push to the 6.12-branch once I get more confirmations that it's working properly.

[ernstp]

I'll have to return my 4770 to the store (lot's of 3D crashes) so I can't give it any more testing right now.

[ernstp]

Right, got a perfectly working 4770 now! Any updates on the subject?

[bridgman]

AFAIK the 4770s we ordered arrived, agd5f plugged one in, and he said "it worked fine". Not sure if that included acceleration support or not; at the time I assumed it did but I don't actually remember seeing 740 IDs added to drm.

We also added the IDs to the 6xx-rewrite branch of mesa, but we have to get a memory manager issue figured out there before that code will do much for you.

[ernstp]

Right so it "works" in shadowfb mode, but there's still a lot to do...
mesa/drm, mesa/mesa, kernel/kms to support Xv, EXA and finally 3D.

[bridgman]

Just to be clear, we're talking about "works at the same level as other cards in the family", ie EXA and Xv but not 3D yet.

I don't know if drm support for EXA/Xv is in the 2.6.30 kernel or not; I was under the impression that it was but with agd5f away I'm not 100% sure.

[ernstp]

Just to be clear, we're talking about "works at the same level as other cards in the family", ie EXA and Xv but not 3D yet.

I don't know if drm support for EXA/Xv is in the 2.6.30 kernel or not; I was under the impression that it was but with agd5f away I'm not 100% sure.

Oh, I was waiting for it to show up here http://cgit.freedesktop.org/mesa/drm/tree/linux-core (on some branch, like r6xx & r7xx support) but there's nothing. Instead some searching gave me this: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=2a71ebcd85bcc4d6607f577f23a491f 796c30e82
So I guess you're right, but you've must have change how you work or something?

[bridgman]

Back when drm was relatively simple, it was practical to keep a single copy of the source which was compatible with a broad range of kernel versions, and that tree was kept in freedesktop.org. That approach was convenient in a whole lot of ways.

As the drm code became more complicated (memory management, modesetting, plus an increasingly sophisticated "legacy" implementation, it became harder to keep the code working across a range of kernel versions and the "official" work gradually moved into branches of the Linux kernel tree rather than fdo.

This makes things a bit harder for other OSes, and requires relatively more adoption of the latest kernel to enable hardware and features, but it does seem to be the only practical way for the developers to keep up with the workload.

Right now I believe the drm code in freedesktop.org works up to ~2.6.28, and for anything newer you need to start picking up WIP kernel trees or developer branches off the kernel tree.

Dave proposed this a year or two ago; it wasn't very popular but I think there was a reluctant admission that the change probably had to happen unless a whole new pile of developers suddenly appeared.