Announcement

Collapse
No announcement yet.

AMD Releases Radeon HD 6000 Series Open-Source Support

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

  • zoomblab
    replied
    @MaestroMaus
    I apologize for my harsh words.

    Leave a comment:


  • MaestroMaus
    replied
    Originally posted by Kano View Post
    The "same" driver? Well i never saw an unsupported hardware watermark or testing watermark with Win beta drivers, did you?
    You know what I mean Kano.

    Leave a comment:


  • bridgman
    replied
    That is correct. The Windows drivers simply refuse to light up unsupported hardware. Linux drivers light the card up but display the watermark.

    Leave a comment:


  • Kano
    replied
    The "same" driver? Well i never saw an unsupported hardware watermark or testing watermark with Win beta drivers, did you?

    Leave a comment:


  • MaestroMaus
    replied
    Originally posted by zoomblab View Post
    @MaestroMaus
    We all appreciate the efforts of open source developers. It is cynical smart-asses that we don't. The persons you mentioned expressed valid concerns about the way those efforts are delivered to the end user.

    The process of updating drivers is no-doubt flawed. It has to be dynamic, flexible, autonomous, non-centralized, non-distro dependant, ...
    Are you kidding me? There where close to zero good arguments there. I will show you what I mean:

    We don't need to wait for some years for a new version of Windows to run a new graphics card...
    Do I need to point out you don't need to wait on Linux for that? The same windows drivers are available on Linux. Furthermore, it's unrealistic to think opensource drivers can progress this fast. One of the reasons therefor would be much less manpower.

    I struggle to understand why so many other packages need to be updated (kernel, mesa, etc) for a new ati driver to be released. Why are they so tightly coupled?
    This one is slightly better. I have admit here: I don't know if they need to be this tightly coupled. What I do know is that it doesn't matter for the speed of development. It's a manpower issue. If anything, making more modularized versions takes probably more work.

    Leave a comment:


  • zoomblab
    replied
    @MaestroMaus
    We all appreciate the efforts of open source developers. It is cynical smart-asses that we don't. The persons you mentioned expressed valid concerns about the way those efforts are delivered to the end user.

    The process of updating drivers is no-doubt flawed. It has to be dynamic, flexible, autonomous, non-centralized, non-distro dependant, ...

    Leave a comment:


  • Mazur
    replied
    Woah AMD, now I am seriously thinking about coming back to my old HD 5670 (or 5650, I can't remember) from NVIDIA 8600 GT but seriously how is support for Evergreen now comparing to this HD 6000?

    Leave a comment:


  • xir_
    replied
    Originally posted by bridgman View Post
    <RANT>
    A two minute edit window would actually give me time to edit the post without having the submit fail after editing
    </RANT>
    but then you could reconsider some juicy information you accidentally post.

    Leave a comment:


  • MaestroMaus
    replied
    Originally posted by FunkyRider View Post
    The whole linux graphics driver stack is flawed.

    We don't need to wait for some years for a new version of Windows to run a new graphics card, instead we install the vendor provided driver.

    Without the ability to dynamically expand drivers, Xorg will forever be the second class citizen in graphics world.
    Originally posted by leif81 View Post
    I agree. As good a state as the ati open source drivers are in...having to wait 12 months from the time the hardware was released until out of the box support lands in a Fedora/Ubuntu is just far too long.

    I struggle to understand why so many other packages need to be updated (kernel, mesa, etc) for a new ati driver to be released. Why are they so tightly coupled? Is this the fault of the ati driver implementation? Why not write the driver for current kernel releases and then update it as the new kernels and mesa are released?
    It baffles me that you know exactly what you are talking about. That's right, all the developers are wrong. Damn how could they have been so stupid. Clearly, we should have more random people talking about how things should be run here. Also, I love how you guys are willing to donate code and money for this community project. It's good to know that whenever other people are devoting time and money, someone is there to help and support them.[/sarcasm]

    If you want to use Linux on your desktop, deal with the low market share and thus with the slower development speed. You didn't buy anything and the community does not owe you anything. Be happy with what you get for a change. I haven't had the option of open source drivers for seven years and there are plenty of folks here who can multiply that a few times.

    Leave a comment:


  • bridgman
    replied
    Mesa *is* the 3D driver, so the 3D HW acceleration code goes into Mesa.

    The kernel driver handles modesetting, command submission and memory management, while the X driver (ddx) handles 2D and video acceleration along with legacy modesetting code from the UMS days. The driver stack just happens to have four major components -- X driver, 3D driver, kernel driver and userspace kernel driver interface (libdrm). This is not a radeon-specific thing -- all drivers use the same architecture.

    Now, if you were to ask "why don't all the components work on the same release schedule ?", that would be a good question. The community is moving towards a synchronized quarterly release cycle but getting there takes time. The next step would be to synchronize distro release cycles and the underlying driver release cycles (there has been some discussion of this in the past) but now you are trying to synchronize an even larger number of independent groups.

    <RANT>
    A two minute edit window would actually give me time to edit the post without having the submit fail after editing
    </RANT>

    Leave a comment:

Working...
X