Page 4 of 10 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 96

Thread: Radeon OpenGL 2.0 support

  1. #31
    Join Date
    Jul 2008
    Posts
    40

    Default

    Quote Originally Posted by agd5f View Post
    fglrx will still work with his hardware if he doesn't mind using a supported kernel and xserver.
    Which is very crippling in the linux world. Most distroes are release locked. I guess I could fine tune stuff like Arch but it requires a lot of work since you need to lock a nice set of packages and hope for the best.

  2. #32
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

    It's probably easier to stay with the distro that worked for you before, at least until the open source drivers are at a point where they do what you need. For everything except gaming the open source drivers are probably at that point already.

  3. #33
    Join Date
    Aug 2006
    Posts
    90

    Default

    Seriosuly - use an older distro which has support (you can even dual boot if you need newer software - I doubt you need GLSL 100% of the time) or you could do what I did and buy a new card that is fully supported by fglrx and wait for the open source drivers to improve. Chances are a new card will be < $100 and shows ATI/ AMD that supporting Linux users is a good business decision.

  4. #34
    Join Date
    Jul 2008
    Posts
    40

    Default

    Quote Originally Posted by Tillin9 View Post
    Seriosuly - use an older distro which has support (you can even dual boot if you need newer software - I doubt you need GLSL 100% of the time) or you could do what I did and buy a new card that is fully supported by fglrx and wait for the open source drivers to improve. Chances are a new card will be < $100 and shows ATI/ AMD that supporting Linux users is a good business decision.
    I can't because it's a laptop. And my main focus is development, not gaming (although there's some gaming development going on ).

    I'm not whining, but IMHO AMD/ATI could put more effort in this. If it was windblows, the drivers would be in long time ago. Still, I applaud all the effort and see great things coming after these abstractions stabilize.

  5. #35
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

    Quote Originally Posted by Almindor View Post
    If it was windblows, the drivers would be in long time ago.
    Actually we dropped support for Linux and Windows at the same time. The issue, I think, is that new versions of Windows normally work with older drivers (eg Vista could use XP drivers and Win7 can use Vista drivers).

    Linux changes more frequently, with API changes happening every few months rather than every few years, and requires constant driver updates in order to keep working with changed X and kernel versions. There is no attempt to make use of drivers which supported the previous API; drivers have to constantly change in order to keep working (unlike Windows where a driver from two years ago is often still useful).

    The kernel changes are particularly expensive when functions the driver relies on are marked GPL-only, ie saying "binary drivers can't use this functionality any more, you have to redesign the bottom end of your driver and find another way to do the same thing".
    Last edited by bridgman; 10-13-2009 at 12:31 PM.

  6. #36
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    Quote Originally Posted by bridgman View Post
    The kernel changes are particularly expensive when functions the driver relies on are marked GPL-only, ie saying "binary drivers can't use this functionality any more, you have to redesign the bottom end of your driver and find another way to do the same thing".
    I'm very curious about this; does it happen often? Is there a _technical_ reason behind it?

  7. #37
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,149

    Default

    Quote Originally Posted by yotambien View Post
    I'm very curious about this; does it happen often? Is there a _technical_ reason behind it?
    Yes.

  8. #38
    Join Date
    Nov 2008
    Posts
    780

    Default

    Quote Originally Posted by yotambien View Post
    I'm very curious about this; does it happen often? Is there a _technical_ reason behind it?
    yes, creating a stable interface and sticking to it is a lot of work.

    Microsoft only releases a new kernel every couple of years. They usually provide compatibility wrappers for old APIs.

    Linux is different. Frequent releases means that all API-changes are public at some point and the amount of compatibility wrappers to write are much higher. But the only drivers suffering from these problems are binary drivers - OS-drivers that were merged into the kernel-tree are updated by the kernel maintainers on every API change and will always work.

    So maybe it's not strictly a technical reason, but do you expect the kernel developers to do a huge amount of extra work to cater for closed source drivers that nobody really likes?

    For further reading, try this and google for the resulting discussion.

  9. #39
    Join Date
    Oct 2007
    Posts
    52

    Default

    Quote Originally Posted by bridgman View Post
    Linux changes more frequently, with API changes happening every few months rather than every few years, and requires constant driver updates in order to keep working with changed X and kernel versions. There is no attempt to make use of drivers which supported the previous API; drivers have to constantly change in order to keep working (unlike Windows where a driver from two years ago is often still useful).

    The kernel changes are particularly expensive when functions the driver relies on are marked GPL-only, ie saying "binary drivers can't use this functionality any more, you have to redesign the bottom end of your driver and find another way to do the same thing".
    This is not quite fair to say bridgman. The _external_ kernel API doesn't change frequently at all.

    The _internal_ API of the kernel however does change in the way you describe. If your driver uses the external API of the kernel only (when it is in userspace) then your driver would only very infrequently need updates for changed APIs.

    If your driver uses the internal API however, then yes, you'll have to deal with the internal API changes. That's the tradeoff. And yes I know, in order to get any performance at all you'll at least need part of your driver in kernel space.

    This is a classical dilemma for proprietary drivers.
    Which is also why open sourcing your driver/specs is such a good idea :-)

    Also, comparing the Windows lifecycle with the Linux lifecycle is quite unfair as well, they are completely different. Linux thrives on the ability to change internal APIs as you well know. For example, how else could G3D ever have come to life?

  10. #40
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    I asked a very specific and simple question:

    Quote Originally Posted by yotambien
    Quote Originally Posted by bridgman
    The kernel changes are particularly expensive when functions the driver relies on are marked GPL-only, ie saying "binary drivers can't use this functionality any more, you have to redesign the bottom end of your driver and find another way to do the same thing".
    I'm very curious about this; does it happen often? Is there a _technical_ reason behind it?
    You decided to ignore it and provided, yet again, an unrelated link to the same old propaganda. Next time don't forget to include Arjan's doomsday scenario for good measure.

    On the meanwhile, I found a more appropriate answer in the linux-kernel mailing list faq:

    # What is this about GPLONLY symbols?

    * (REG) By default, symbols are exported using EXPORT_SYMBOL, so they can be used by loadable modules. During the 2.4 series, a new export directive EXPORT_SYMBOL_GPL was added. This is almost the same thing, except that the symbol can only be accessed by modules which have a GPL compatible licence (note that this includes dual-licenced BSD/GPL code). This new directive was added for these reasons:
    o To clarify the ambiguous legal ground on which non-GPL (particularly proprietary) modules lie. A strict reading of the GPL prohibits loading proprietary modules into the kernel. While Linus has consistently stated that proprietary modules are allowed (i.e. he has granted an explicit exemption), it is not clear that he is able to speak for all developers who have contributed to the Linux kernel. While many think Linus' edict means that all contributed code falls under this exemption granted by Linus, not everyone agrees that this is a legally sound argument. The new EXPORT_SYMBOL_GPL directive makes the licence conditions explicit, and thus removes the legal ambiguity.
    o To allow choice for developers who wish, for their own reasons, to contribute code which cannot be used by proprietary modules. Just as a developer has the right to distribute code under a proprietary licence, so too may a developer distribute code under an anti-proprietary licence (i.e. strict GPL).
    Note that Linus has stated that existing symbols will not be switched to GPL-only. Developers of proprietary modules for Linux need not fear. Furthermore, it is quite unlikely that Linus will look favourably upon the introduction of new core driver APIs which are restricted to GPL-only modules. This would not be in the best interests of Linux. Linus has forwarded me a message he sent to someone else to clarify his views. Note that since that time, several developers have eroded the number of non-GPL only symbols by writing new (usually better) infrastructure and interfaces and deprecating the older interfaces. The newer interfaces are often tagged as GPL-only. In addition, there are some "kernel janitors" who aggressively submit patches to remove all symbols (whether GPL-only or not) which are not used by code shipped with the kernel source tree.
    So no, no technical reason whatsoever.

Posting Permissions

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