Page 8 of 9 FirstFirst ... 6789 LastLast
Results 71 to 80 of 88

Thread: AMD Has Open-Source Driver For HD 8000 Series

  1. #71
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    Quote Originally Posted by curaga View Post
    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.

  2. #72
    Join Date
    Oct 2008
    Posts
    3,025

    Default

    Quote Originally Posted by curaga View Post
    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.

  3. #73
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default

    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.

  4. #74
    Join Date
    Aug 2008
    Location
    Tokyo, Japan
    Posts
    36

    Default

    Quote Originally Posted by curaga View Post
    [...] 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.

  5. #75
    Join Date
    Oct 2008
    Posts
    3,025

    Default

    Quote Originally Posted by curaga View Post
    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.

  6. #76
    Join Date
    Dec 2007
    Posts
    2,320

    Default

    Quote Originally Posted by curaga View Post
    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.
    Last edited by agd5f; 02-11-2013 at 10:16 AM.

  7. #77
    Join Date
    Oct 2009
    Location
    Brisbane, Queensland, Australia
    Posts
    147

    Default

    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?

  8. #78
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    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".

  9. #79
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    904

    Default

    Quote Originally Posted by bridgman View Post
    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".
    Thanks for clarification!

    I was surprised to read that AMD postpones the release of the new GCN2 ASICs
    to late 2013 while the first bits of driver support hit the repositories.

  10. #80
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default

    MrCooper, agd5f, thanks for the clarification.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •