Announcement

Collapse
No announcement yet.

AMD Has Open-Source Driver For HD 8000 Series

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    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.

    Comment


    • #72
      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.

      Comment


      • #73
        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.

        Comment


        • #74
          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.

          Comment


          • #75
            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, 10:16 AM.

            Comment


            • #76
              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?

              Comment


              • #77
                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".

                Comment


                • #78
                  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.

                  Comment


                  • #79
                    MrCooper, agd5f, thanks for the clarification.

                    Comment


                    • #80
                      Originally posted by entropy View Post
                      I was surprised to read that AMD postpones the release of the new GCN2 ASICs to late 2013...
                      We were surprised to read that too. It's funny how when rumour A is replaced by rumour B people automatically assume that *we* changed something

                      Comment

                      Working...
                      X