AMD Has Open-Source Driver For HD 8000 Series

[bridgman]

While AMD has yet to officially introduce their Radeon HD 8000 series, published today was the initial open-source Linux graphics driver support for handling the Radeon HD 8800 "Oland" graphics cards.

AMD's been planning for a second quarter release of the Radeon HD 8000 "Sea Islands" GPUs while the first to arrive hardware will be the HD 8800 "Oland" graphics processors. This hardware that succeeds the Radeon HD 7000 series isn't as radically different as going from the HD 6000 to HD 7000 series, which yielded a better turnaround time with the initial HD 8000 series support.

Just noticed that the article links the just-released driver support for Oland to an HD 8800-series part, presumably based on September 2012 rumours which described Oland as a 3.4 billion transistor upper-midrange part.

Oland is actually a 6 CU part (ie same ALU count as the GPU on Trinity, but GCN rather than VLIW4). See Anandtech description of Oland/Mars :

Oland : http://www.anandtech.com/show/6570/a...eries-for-oems

Mars : http://www.anandtech.com/show/6571/a...n-8000m-series

The "Oland" support we pushed recently was for the HD 85xx/86xx OEM and mobile parts announced in January, not for "HD 8800".

[madbiologist]

No code for/discussion about Richland APU's (the successor to the current Trinity APU's)? Supposedly they will be launched on March 19th 2013 and apparently will be built with Piledriver cores and HD8000 graphics cores while maintaing the same TDP. Does anyone know if any of this is true?

[agd5f]

Perhaps you missed my post above - the scanline wait removes tearing, while being lighter than a compositor, no?

In practice, it's pretty much the same. You generally only have time for one scanline wait per frame anyway, and if your image is anywhere close to the height of a frame, you end up waiting for almost an entire frame anyway. Additionally, a scanline wait stalls the 3D engine will you wait for the vline so during that time you can't be rendering something else.

Plus, with a compositor, you can pageflip which saves memory bandwidth over a blit.

[smitty3268]

Because not using a compositor in X works, right now.

That's not a reason to keep doing it - just a statement of fact about the sucky way things work now.

[MrCooper]

[...] the scanline wait removes tearing, while being lighter than a compositor, no?

Not necessarily, on both counts:

With the scanline wait, there can still be a tearing effect between different parts of the screen which are updated separately.

Also, the scanline wait stalls the entire graphics pipeline. In extreme cases such as e.g. glxgears running fullscreen, this means the pipeline can effectively only run during the vertical blank interval, even for things not directly related to glxgears.

A sophisticated compositor such as Weston allows eliminating tearing completely while using the full graphics pipeline throughput.

[curaga]

My point was that if you don't want to use a compositor, then why even bother with graphics at all. Forget using Wayland or X and just use the console.

Because not using a compositor in X works, right now.

[smitty3268]

Sorry, I'm not following you?

me: forcing people to a compositor is no solution
you: here's a compositor
me: you lack reading comprehension
you: use the console

How the heck did step 4 follow from step 3?

Dude, it was a joke. Relax.

My point was that if you don't want to use a compositor, then why even bother with graphics at all. Forget using Wayland or X and just use the console.

Joke.

[bridgman]

I assume the scanline wait code is smart enough to calculate the needed time and to avoid the scanline catching up in the middle of a transfer.

You would either have to have the kernel driver pick apart every command buffer and estimate both the time required for each one *and* the screen area covered by the operation, or you would need to limit drawing operations to more-or-less the vertical blanking interval. Even that wouldn't cover the problem Drago is talking about, which is running into the scanline pause mid way through redrawing the screen.

You really need double-buffering to let the app or desktop manager draw complete frames without ending up displaying a half-redrawn screen and allow whole frames to be flipped in when complete.

*IF* your app/DE never redraws the screen but just makes a series of changes to small parts while leaving the rest unchanged you can get away with limiting drawing operations to a small part of the vertical refresh period, but AFAIK apps & DE's are less likely to work like that every year.

[curaga]

What about scan line is about to start, but the app haven't refreshed its entire framebuffer. You still have tearing, this time it is per app.

I assume the scanline wait code is smart enough to calculate the needed time and to avoid the scanline catching up in the middle of a transfer.

[Drago]

Perhaps you missed my post above - the scanline wait removes tearing, while being lighter than a compositor, no?

What about scan line is about to start, but the app haven't refreshed its entire framebuffer. You still have tearing, this time it is per app.