Announcement

Collapse
No announcement yet.

Digging Deeper Into AMD's UVD Code Drop

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

  • brosis
    replied
    Originally posted by smitty3268 View Post
    To be fair, that post you found is from 2.5 years ago, and the OSS drivers have improved immensely in the time sense then.

    I would still probably recommend sticking with Intel in any laptop you buy, but I don't think you can really draw many, if any conclusions about the current driver based on what it was like 3 years ago.
    Well... I ended purchasing 17" notebook with AMD Mobility X1900+core2duo, that poped out of the sudden.

    Mostly because it has better 3D and one of the hackers has managed to edit the fan control directly, so the system can at least be cooled off efficiently.

    So without opensource driver and community, amd had had no chance by me.

    I will look up how well it performs. I can sell the system and migrate to all-Intel quite quickly actually if it does not work out.

    Lets see how it turns.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by brosis View Post
    Excuse me, gentlemen, for slight hijacking into the topic. This is real-world use case.
    I am looking for a good used notebook, preferably IBM. So I found "as new" T60. It has Intel chip, so I hope for good stable open intel graphics.

    One of them is T60p - p="professional" meaning more advanced graphics. Then I see - "Ati FireGL5200". I decided to ignore it, because I know - its crap.
    But still, I googled a bit. Confirmation: "Welcome to a world of pain."

    "Performance" my ***...

    Another 200$ going into Intel for good opensource blob-free working driver.
    Have a nice conversation, excuse me for interruption.
    Hey, thank you for the trolling!

    We really appreciate it! You can be proud of yourself dude!!!

    Leave a comment:


  • Deathsimple
    replied
    To anybody interested:

    I pushed the UVD userspace patches to mesa master today. Matching kernel patches can be found here: http://cgit.freedesktop.org/~agd5f/l...-next-3.10-wip

    Cheers,
    Christian.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by brosis View Post
    Excuse me, gentlemen, for slight hijacking into the topic. This is real-world use case.
    I am looking for a good used notebook, preferably IBM. So I found "as new" T60. It has Intel chip, so I hope for good stable open intel graphics.

    One of them is T60p - p="professional" meaning more advanced graphics. Then I see - "Ati FireGL5200". I decided to ignore it, because I know - its crap.
    But still, I googled a bit. Confirmation: "Welcome to a world of pain."

    "Performance" my ***...

    Another 200$ going into Intel for good opensource blob-free working driver.
    Have a nice conversation, excuse me for interruption.
    To be fair, that post you found is from 2.5 years ago, and the OSS drivers have improved immensely in the time sense then.

    I would still probably recommend sticking with Intel in any laptop you buy, but I don't think you can really draw many, if any conclusions about the current driver based on what it was like 3 years ago.

    Leave a comment:


  • entropy
    replied
    Originally posted by Hirager View Post
    However, it [firmware] definitely is not software, so it should not be bound by same set of rules as software.
    Why? Care to explain?

    Leave a comment:


  • brosis
    replied
    Excuse me, gentlemen, for slight hijacking into the topic. This is real-world use case.
    I am looking for a good used notebook, preferably IBM. So I found "as new" T60. It has Intel chip, so I hope for good stable open intel graphics.

    One of them is T60p - p="professional" meaning more advanced graphics. Then I see - "Ati FireGL5200". I decided to ignore it, because I know - its crap.
    But still, I googled a bit. Confirmation: "Welcome to a world of pain."

    "Performance" my ***...

    Another 200$ going into Intel for good opensource blob-free working driver.
    Have a nice conversation, excuse me for interruption.

    Leave a comment:


  • Kano
    replied
    Well the drivers are not really much different. Usually you can fake workstation hardware with a simple fglrx kernel module hack as the check is in the open source part. It does not give you more game performance, just workstation benchmarks like specviewperf run faster.

    Leave a comment:


  • bridgman
    replied
    Originally posted by Hirager View Post
    I keep wondering, why corporations like AMD keep pushing out so many different products which differ only a bit. I believe THIS is a waste of R&D.
    We usually only offer two variants -- consumer and workstation -- and those differ primarily in the binary drivers (although clock speeds, testing, components etc.. are usually also different).

    The rest of the variety comes from our board partners who buy chips from us and design/build their own boards starting with a reference design from AMD.

    The discussion about limiting functionality in microcode is hypothetical, offered as a possible reason for having more concerns about RAM-based microcode than equivalent ROM-based microcode. It doesn't really apply to open source drivers anyways since vendors can't "force" a microcode update on users, but it might help to explain some of the instinctive dislike.

    Leave a comment:


  • Hirager
    replied
    I have just read this passionate discussion about software, firmware and hardware, and concluded that an essential element is still missing in this SOFT <-> HARD war. A proper definition of what firmware truly is. For me, firmware is exactly the interface between the code and the machine. A layer translating software into hardware, and hardware into software. Nothing more, nothing less. It doesn't matter where it resides. It is NOT software AND it is NOT hardware. It is up to authorities like Richard Stallman to decide whether it should be "free" or not. However, it definitely is not software, so it should not be bound by same set of rules as software.

    In this scientific light I can see a way out of this conflict. If current "microcode blob" contains code that does not serve the soft <-> hard translation purpose then move it out. Do what you want with the rest of code. If a market segmentation is required, do it in hardware. If there are too many models of products to manage that - manufacture less models. I keep wondering, why corporations like AMD keep pushing out so many different products which differ only a bit. I believe THIS is a waste of R&D. Why not put out just 3 new models in each new line (best performance, cheapest, balanced) and update previous models to newest tech without changing basic parameters? How about this?

    In this discussion I am sure on two opinions:
    1. Post-production limitation of hardware is bad practice.
    2. Firmware is neither software nor hardware, it is a completely separate unit which ties software and hardware together.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by hfernando View Post
    :c It didn't work for me. I downloaded a patched sources from git://people.freedesktop.org/~deathsimple/linux , the uvd-3.9 branch and a the patches for mesa-9.2 from the mail list.
    I would report this but i don't know where. because of DRM think.
    Did you get the new firmware too?

    Leave a comment:

Working...
X