Page 9 of 19 FirstFirst ... 7891011 ... LastLast
Results 81 to 90 of 184

Thread: AMD Linux Catalyst: Hardware Owners Screwed?

  1. #81
    Join Date
    Oct 2007
    Posts
    284

    Default

    My initial thought was "ahh, those darn ****" but now that i think about it again it might actually be a good thing.

    Some facts.
    - AMD _is_ working on supporting KDE/KWin thus probably fixing up direct rendering. The confirmed that in a bug report. http://ati.cchtml.com/show_bug.cgi?id=312
    - AMD was/is looking into ways to get the UVD API exposed in Linux as you keep reading about on phoronix from time to time.
    - AMD did say that the 8xxx series card should have out of the box support from the OPENSOURCE radeon driver.

    All of those where articles on phoronix as well. Search for them.
    When is the 8xxx series going to be here?.. Well, if we look at AMD's previous graphic card releases then we should see some releases by the end of this year! That means that they should have a great deal of opensource radeon driver (radeon-si) code already created or developers should be very hard at work on that right now. And that would fit the recent (public) inactivity of radeon-si. Just look at http://cgit.freedesktop.org/~agd5f/mesa/log/ and you'll see only one big commit for initial SI support. There must be SO MUCH MORE hidden in some personal git repository of some AMD devs. Usually when there is a long period of seemingly no progression you get sudden bursts of big code and a lot of features. Just for fun, search for commits from Tom Stellard. His last big one was the initial SI code dump and there was nothing from him for a after that or before that for at least a couple of months. I'm betting he alone had a lot of stuff waiting to be pushed to the public.

    -- edit: http://cgit.freedesktop.org/~tstellar/opencl-example/ Guessing he got an assignment to work on OpenCL ^_-
    -- edit2:http://cgit.freedesktop.org/mesa/mesa/log/ He's actually working on LLVM right now since those commits are just a few days old. It's amazing what you can find out by looking at commit messages. Yet again, only guessing here!

    My guess is: It has to go from bearable to unbearable before it gets better quite quickly and better then ever before. Right now we are in the transition from bearable to unbearable. I'm guessing we well be in that "phase" for a few months till we see a massive code dump from AMD in the radeon-si repository.

    If this all plays out the way i think it will (and i'm only connecting dots with the above info, i'm by no means an AMD employee or anything like that) then we should be getting in a whole better shape somewhere near the end of this year. So i'm quite optimistic though it wouldn't be the first time that AMD disappoints in expectations so all of this could be completely nonsense.


    As for the binary. Didn't they say that there wasn't going to be a binary driver anymore from starting from the 8xxx series? In that case this move makes sense since then they are phasing out the current binary driver. In that same case it doesn't make sense that the old hardware support is dropped since the driver is going to be here for a few more months anyway.. I'm missing a connection in this part.

    That's my point of view. It needs to get worse before it gets better so just wait a few months. If it ends up nasty after all, we can still move to nvidia
    Last edited by markg85; 06-01-2012 at 05:05 AM.

  2. #82
    Join Date
    Apr 2011
    Location
    Slovakia
    Posts
    75

    Default Did hell freeze over?

    I also do not like AMD to drop R600/R700 but I exclusively use OSS radeon+Mesa R600g driver (even though its 3D is bad on my simple HD4350).

    However, in this very negative thread I could find something positive:

    I congratulate Qaridarium to having kept his comments on topic and actually there were informative and even positively meant sentences.

    (This post is not meant to be sarcastic, I really mean it.)

  3. #83

    Default

    Quote Originally Posted by markg85 View Post
    AMD _is_ working on supporting KDE/KWin thus probably fixing up direct rendering. The confirmed that in a bug report. http://ati.cchtml.com/show_bug.cgi?id=312
    Fix already available.

  4. #84
    Join Date
    Oct 2007
    Posts
    912

    Default

    From reading that, power management can be written (via direct control of voltage levels & clock speeds), but automated control (via hardware blocks) isn't yet available. Which is a little different to what you were saying - although I would agree with optimum dynamic power management can not yet be done directly from released docs.

  5. #85
    Join Date
    Feb 2012
    Posts
    444

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    Last time I check (Ironlake) it was slower than software decoding.
    I *own* Ironlake, so I can tell you first hand you're wrong.

    Quote Originally Posted by RussianNeuroMancer View Post
    Same for Intel - they can't write proper vsync.
    Yes, lack of docs to write proper power management is totally the same as vsync issues. Like totally. Master of diversion, that's what you are. There's just one little problem for you - the vsync issues on SNB can be worked around by using a gl compositor. Lack of docs can't be worked around.

    @mirv: Yeah, some sort of power management can be written, something better than what's currently available. But proper support depends on AMD releasing more docs.
    Last edited by Gusar; 06-01-2012 at 05:15 AM.

  6. #86
    Join Date
    Oct 2007
    Posts
    284

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    Thanks a lot for that! Didn't know about that one. Going to give that a test when i get home

  7. #87
    Join Date
    Jan 2008
    Posts
    206

    Default Hmm

    The currently horrible state of Catalyst for Linux is making me really reconsider wether Is hould buy a Trinity based Laptop.
    Catalyst is utter crap and because of Catalyst, the open-source drivers aren't getting the attention they would require to get to acceptable levels.

  8. #88

    Default

    Quote Originally Posted by Gusar View Post
    I *own* Ironlake, so I can tell you first hand you're wrong.
    Blu-ray playback?
    Quote Originally Posted by Gusar View Post
    Yes, lack of docs to write proper power management is totally the same as vsync issues. Like totally.
    For people who cry blood when they see tearing (like me) vsync issues even worse.
    Quote Originally Posted by Gusar View Post
    the vsync issues on SNB can be worked around by using a gl compositor
    With RC6 that doesn't help.
    Quote Originally Posted by Gusar View Post
    But proper support depends on AMD releasing more docs.
    Prooflink, please. Not link to some page this time, only link to message and quote from this message.

  9. #89
    Join Date
    Aug 2007
    Posts
    6,613

    Default

    @RussianNeuroMancer

    Ironlake exposes H264 accelleration via vaapi. I think MPEG2 as well, i just didnt use my i5-680 cpu for over a year because i prefer my i7-880 and i only have got one board for it. Compared to SNB/IVB the missing codec is VC1 (and the hardware h264 encoder for i3-2/3+).

  10. #90

    Default

    Quote Originally Posted by Kano View Post
    Ironlake exposes H264 accelleration via vaapi.
    Sure, I know. I even have a talk with Eugeni Dodonov about this issues with driver, but he not found solution yet. In my opinion hardware limitation.

Posting Permissions

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