Announcement

Collapse
No announcement yet.

The Slides Announcing The New "AMDGPU" Kernel Driver

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

  • drSeehas
    replied
    Originally posted by Luke_Wolf View Post
    Because it's putting the cart before the horse.

    Let me put this in an analogy for you

    Imagine you've got one guy who has got a house with all kinds of expansions and neat features we'll call him AMD Linux, then we've got another guy who has the foundation laid but is still working on setting up the framework of the house, we'll call him BSD Graphics. It's not really useful for AMD Linux to talk to BSD Graphics about all the new cool home expansions and systems he's setting up, when BSD Graphics doesn't even have his house finished yet. On the other hand what BSD Graphics could really use is for AMD Linux to come over and help him get his house built.
    I see it different:

    Once upon a time in the old days of FOSS the developers wanted their software tu run on as much as possible OSs or in your analogy: fit in as much as possible houses. Both, the *BSD and Linux houses, were treated equally and were fully functional, working, usable and livable houses "with all kinds of expansions and neat features".

    Then some day the makers for e.g. the windows (ha!) decided to only support the Linux houses.
    A window consist among other things of the frame and the glass. The *BSD houses (were forced to) keep the old frames and only one glass maker (nVIDIA) still supports at least one of these old frames in the *BSD houses.

    Now another glass maker (AMD) announces the development of a new glass. Wouldn't it be a good idea to develop this new glass in a way, that it will fit also in the old frames of the *BSD houses?
    If the glass maker of the new glass cares about the *BSD houses it would visit these houses and look how these old frames are designed so the new glass will fit easily into these old frames.

    Yes, I know, the story above is simplified.

    ...
    In short you say the *BSDs should go the Linux way as DragonflyBSD plans already.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by drSeehas View Post
    ??? Why?
    Because it's putting the cart before the horse.

    Let me put this in an analogy for you

    Imagine you've got one guy who has got a house with all kinds of expansions and neat features we'll call him AMD Linux, then we've got another guy who has the foundation laid but is still working on setting up the framework of the house, we'll call him BSD Graphics. It's not really useful for AMD Linux to talk to BSD Graphics about all the new cool home expansions and systems he's setting up, when BSD Graphics doesn't even have his house finished yet. On the other hand what BSD Graphics could really use is for AMD Linux to come over and help him get his house built.

    Originally posted by drSeehas View Post
    You mean adapting to the Linux flavor?
    Yes adopting the modern KMS infrastructure and friends

    Originally posted by drSeehas View Post
    Oh, the new AMDGPU kernel drivers are already there?
    They're not public yet but they already exist as a variant of the Radeon kernel driver, yes
    Originally posted by drSeehas View Post
    As I wrote previously: There should be talks before releasing the new drivers.
    And what use would that be? I've seen nothing that implicates that AMDGPU is going to change the kernel infrastructure around the GPU drivers as opposed to the changes being encapsulated inside the AMDGPU kernel driver itself. Further even if that were the case BSD doesn't have enough together to really even talk about it at this point

    Originally posted by drSeehas View Post
    So you think the discussion will be usefull after the new AMDGPU driver is released?
    My opinion: Then it is far too late :-(
    Not after AMDGPU driver is released, after BSD gets their graphics stack modernized regardless of the release status of AMDGPU at that point

    Originally posted by drSeehas View Post
    And making the porting to the *BSDs easier would be a lot of help too.
    Talking won't make porting easier, not right now anyway. Actually helping to build the required infrastructure so that BSD Graphics can have a house so that they can then actually have a basis from which to talk about expansions will.
    Last edited by Luke_Wolf; 14 October 2014, 06:11 PM.

    Leave a comment:


  • drSeehas
    replied
    Originally posted by Luke_Wolf View Post
    ... the *BSDs really aren't in a spot right now where talk is useful, ...
    ??? Why?

    ... they need to finish modernizing their stack ...
    You mean adapting to the Linux flavor?

    ... and then finish porting the kernel drivers over first ...
    Oh, the new AMDGPU kernel drivers are already there?
    As I wrote previously: There should be talks before releasing the new drivers.

    ... and once they're matched with upstream then discussion on future plans will be useful.
    So you think the discussion will be usefull after the new AMDGPU driver is released?
    My opinion: Then it is far too late :-(

    This all said what the *BSDs really need is help.
    And making the porting to the *BSDs easier would be a lot of help too.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by drSeehas View Post
    AMD could make this porting to the *BSDs (done by the *BSDs) much easier, if AMD talks to the *BSDs before AMD makes any decision during the whole process.

    I am not talking/writing about AMD devs working on the *BSDs side. See above.
    Eh... It's more on the *BSDs to engage in dialog with AMD and get involved with the discussions happening upstream than for AMD to engage with the *BSDs downstream. Besides the *BSDs really aren't in a spot right now where talk is useful, they need to finish modernizing their stack and then finish porting the kernel drivers over first and once they're matched with upstream then discussion on future plans will be useful.

    This all said what the *BSDs really need is help.

    Leave a comment:


  • drSeehas
    replied
    Originally posted by profoundWHALE View Post
    The way I see it, in theory with one unified driver we could see the porting of it over to the BSDs and then the userspace driver should be a lot easier to keep updated/ported if it is needed. ...
    AMD could make this porting to the *BSDs (done by the *BSDs) much easier, if AMD talks to the *BSDs before AMD makes any decision during the whole process.

    ... while I would love better BSD support from AMD, I would rather have more devs working on just the open source Linux side, ...
    I am not talking/writing about AMD devs working on the *BSDs side. See above.

    Leave a comment:


  • profoundWHALE
    replied
    Originally posted by drSeehas View Post
    Will AMD cooperate with the *BSDs and (Open-)Solaris, so we will have a choice (today only nVIDIA) there in the future?
    The way I see it, in theory with one unified driver we could see the porting of it over to the BSDs and then the userspace driver should be a lot easier to keep updated/ported if it is needed. Of course, this would require the BSDs to accept it.

    Honestly, while I would love better BSD support from AMD, I would rather have more devs working on just the open source Linux side, because odds are that awesome will be spread around like a jar of some sweet, sweet, jam.

    Leave a comment:


  • whitecat
    replied
    Originally posted by whitecat View Post
    I don't think AMD will work on this soon, there is more important things on the TODO list before that.
    Moreover, if I remeber a comment from David Airlie or maybe Alex Deucher, there is nothing really magical in Crossfire/SLI. This is about balancing in some manner the rendering a different GPU.
    Such things needs modification in the kernel (?), DRM (?), Mesa (?) that can be done by someone outside of AMD (Red Hat, community, etc.). There is maybe some "magic" number/register to set up but I'm pretty sure AMD will give some help if someone intend to work on this Crossfire support.


    There is exactly 4 years between the former HD4000 series release and the last Catalyst version to support them.
    AMD, Enterprise vendor and the "community" still provides updates to r300 and r600g, and even r200 which so implies hardware from mid-2001.
    And the kernel and xorg packages still includes drivers from even older hardware.

    Please give me a game that HD4000/r600g can't handle correctly with decent performance.
    Wrong thread

    Leave a comment:


  • dungeon
    replied
    Originally posted by smitty3268 View Post
    If you watched the presentation explaining all this, you'd have your answer already.

    The non-pro version exists now because people today rely on the Catalyst driver for GL4, OpenCL2, etc. work that the open driver does not yet provide.

    He pretty much flat out said they'd like to get rid of the remaining Catalyst blob on linux, it's just that Mesa isn't quite there yet and so they have to keep their current customers happy.
    I watched a video, they will do it like they want... so there is no question about that, i suggest what i liked more .

    They can put more resources to opensource driver and mesa UMD... well i avoid using acronym like that , that does not exists in my plan at all, because there is no any collision/competing userspace drivers for the same asic

    If they really want to expand opensource driver and talk about opensource, that is the way i think... OpenGL4 mature, oh that is a nonsense for non-pro users if they actually work more on Mesa instead, isn't it It does not matter if they lag a little with that, if they do a right thing.

    Leave a comment:


  • whitecat
    replied
    Originally posted by Kivada View Post
    Any idea on if/when crossfire will be hammered out?
    I don't think AMD will work on this soon, there is more important things on the TODO list before that.
    Moreover, if I remeber a comment from David Airlie or maybe Alex Deucher, there is nothing really magical in Crossfire/SLI. This is about balancing in some manner the rendering a different GPU.
    Such things needs modification in the kernel (?), DRM (?), Mesa (?) that can be done by someone outside of AMD (Red Hat, community, etc.). There is maybe some "magic" number/register to set up but I'm pretty sure AMD will give some help if someone intend to work on this Crossfire support.

    Originally posted by Slartifartblast View Post
    That is exactly why I buy Nvidia - decent support length.
    There is exactly 4 years between the former HD4000 series release and the last Catalyst version to support them.
    AMD, Enterprise vendor and the "community" still provides updates to r300 and r600g, and even r200 which so implies hardware from mid-2001.
    And the kernel and xorg packages still includes drivers from even older hardware.

    Please give me a game that HD4000/r600g can't handle correctly with decent performance.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by drSeehas View Post
    Will AMD cooperate with the *BSDs and (Open-)Solaris, so we will have a choice (today only nVIDIA) there in the future?
    While it's possible I don't see them actively working with the *BSDs and Solaris, they might help maintain it if/when the respective communities have finished porting it, but I think you're just going to have to wait for the time being. That said the *BSDs are actively porting the modern graphics infrastructure now so hopefully it won't take them too long to get things going.

    Then again with the increased manpower working on the kernel drivers AMD just might. Regardless within a few years (I'm not familiar enough with the efforts to make a real guess at the timeframe) AMD will be available as a proper choice.

    Leave a comment:

Working...
X