Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

  • runeks
    replied
    Yeah, I see your point. I guess Gallium isn't very suited for cross OS compatibility after all, if hacks/intentional bugs added to the Catalyst driver are the norm to make them work faster with buggy games. That just sounds like mess to bring into the Gallium code. If these application-specific hacks could be separated into a specific state tracker, that would help though.

    But on the other hand, if the Gallium infrastructure would save the AMD developers some time in the end, this time could be used to implement further optimizations (that they wouldn't have time to do were they not using Gallium), and thus - perhaps - gaining a bit of the performance back that Gallium takes away in order to reduce complexity?

    But of course if they have to develop the whole thing from scratch because of the IP issues you mention, this obviously isn't a viable option. But I imagine that if it indeed is true that moving the driver development over to Gallium would save time in the end, then this will happen quite automatically and organically, as the Gallium drivers mature, and the advantages, and disadvantages, become more obvious.
    It is with this as with most things probably; a sudden and drastic change - scrapping all Catalyst code, and developing the drivers from scratch for Gallium - doesn't work. Only a slow, gradual migration from the current Catalyst infrastructure to Gallium has a chance to work.

    Leave a comment:


  • glisse
    replied
    Originally posted by runeks View Post
    Is implementing Gallium3D on Windows and Mac OS, to enable cross platform (OS) driver support, in any way realistic?

    Do you think that this would reduce your workload significantly, or are you already, in the development of the Catalyst driver, sharing so much API- and driver code between OSes that Gallium won't make that much of a difference?
    Catalyst code will never be release, too much IP in it. I am pretty sure they will also never switch to gallium even if it's doable to use gallium to do DX or GL driver for windows. Gallium infrastructure is about sharing accross different GPU manufacturer and this means they are design choice that doesn't fit well all the hw but are the best compromise. So for a really fast driver able to squeeze all the performance out of the GPU you need a stack that is designed for it, i believe this is what catalyst is.

    I think bottom line is AMD won't put more $ resource on open source hw unless the suddenly see a load of $ coming back, thing is there is no way for them to know how much an open source driver matter to OEM or HP, Dell, Lenovo ... It's all about selling hw, if having a good open source driver give them a 5% increase or more in market share then they will put resource on open source driver. It's obviously not the case today but things like chromeos or others nettop or laptop design under linux might lead to more incentive from OEM to improve the open source stuff.

    Leave a comment:


  • runeks
    replied
    Originally posted by bridgman View Post
    i know the obvious response at this point will be "but if you moved the catalyst for linux developers to the open source driver then you could have gl4 etc...", but that's not how it works. We develop the catalyst driver code and share it across 100% of the pc market (ie all oses), but if we moved the devs who make that common code available on linux to working on the open source driver then they would not be able to leverage the work done for all of the other oses, ie they would be working on a linux-specific code base, and the same number of developers would *not* be able to deliver the same level of features and performance.

    Put simply, open source drivers share code across hw vendors (ie the intel, radeon and nouveau driver stacks share a lot of common code, which is why they have similar features) while proprietary drivers share code across oses.
    Is implementing Gallium3D on Windows and Mac OS, to enable cross platform (OS) driver support, in any way realistic?

    Do you think that this would reduce your workload significantly, or are you already, in the development of the Catalyst driver, sharing so much API- and driver code between OSes that Gallium won't make that much of a difference?

    Leave a comment:


  • Qaridarium
    replied
    duby229:"I dont think that is what he is saying. I took it as they are working with members of the hardware team and probably also the catalyst team who are now assembling docs and code for the next gen in catalyst. Which means that they can more easily get information that they need in better formats.
    Previous generations of hardware were not documented for open source drivers. Working with the original teams writing docs will help them enormously.
    Reply With Quote Quick reply to this message"

    Originally posted by bridgman View Post
    Right. Nothing to do with Gallium3D vs classic... the r600g driver has *also* reached the point where we're going to use it for initial support of new GPUs, but that is total coincidence.

    What I'm talking about is piggybacking on the "learn about the new HW changes" portion of the SW design effort for proprietary drivers. We're quite late for the 2011 graphics core effort (most of the SW design work is finished) but we should be able to get some benefit anyways.
    well i just din't know that ... and yes i'm happy about that

    2011 will be a good year for the radeon driver

    Leave a comment:


  • bridgman
    replied
    Right. Nothing to do with Gallium3D vs classic... the r600g driver has *also* reached the point where we're going to use it for initial support of new GPUs, but that is total coincidence.

    What I'm talking about is piggybacking on the "learn about the new HW changes" portion of the SW design effort for proprietary drivers. We're quite late for the 2011 graphics core effort (most of the SW design work is finished) but we should be able to get some benefit anyways.

    Leave a comment:


  • duby229
    replied
    Originally posted by Qaridarium View Post
    means ... galium3D is ready and the hd6000 support will come with only galium3D only support

    the classic mesa is not a "proprietary driver design" means they just drop classic mesa.

    why do you don't speak clear words ? like: yay galium3D is ready now we can kill classic mesa ....
    I dont think that is what he is saying. I took it as they are working with members of the hardware team and probably also the catalyst team who are now assembling docs and code for the next gen in catalyst. Which means that they can more easily get information that they need in better formats.

    Previous generations of hardware were not documented for open source drivers. Working with the original teams writing docs will help them enormously.

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by bridgman View Post
    It's been a few months since I mentioned trying to piggyback open source development on the proprietary driver design effort so the open source devs wouldn't have to "learn everything from scratch" and we didn't know exactly when we would be able to start...

    ... but it seems like the right time is "now"
    means ... galium3D is ready and the hd6000 support will come with only galium3D only support

    the classic mesa is not a "proprietary driver design" means they just drop classic mesa.

    why do you don't speak clear words ? like: yay galium3D is ready now we can kill classic mesa ....

    Leave a comment:


  • bridgman
    replied
    It's been a few months since I mentioned trying to piggyback open source development on the proprietary driver design effort so the open source devs wouldn't have to "learn everything from scratch" and we didn't know exactly when we would be able to start...

    ... but it seems like the right time is "now"

    Leave a comment:


  • HokTar
    replied
    Fair enough. Thanks.

    Leave a comment:


  • bridgman
    replied
    Originally posted by chrisr View Post
    Can you remember what was done to fix this "glitching" issue, please? E.g. was it in the kernel, the driver, or Mesa? Because I was noticing some glitchy behaviour with the 2.6.36.1 kernel and xorg-drv-ati from git recently (HD4890).
    Pretty sure it was in the kernel. My guess is that you would need 2.6.37 to get it.

    HokTar, not lowering clock/voltage is what the TODO task (splitting clock adjust for engine & memory into different vblank intervals) is intended to address. If there isn't enough time in a single vblank interval to set and stabilize both clocks the current code doesn't change either of them... and you can't lower the voltage unless the clocks have already been lowered and stabilized.

    Originally posted by HokTar View Post
    Sometimes you show your admirable skill in not answering a question. Not to mention that I never said "a lot".
    No, but you implied "a lot" by suggesting that the devs work on things like assisting Christian's video decode work. The remaining work there is not "quick fixes", there's a fairly significant learning curve on the video algorithm side.

    Originally posted by HokTar View Post
    Plus I had the wild guess that the desktop apu will be based on evergreen or ni thus enabling it might not take much more than for ontario, i.e. a few hundred lines. If this assumption turns out to be correct then there would be two devs with little to no work for months. So yes, maybe that would be a *lot* of free time
    A lot of the work Alex did for Ontario should carry across to Llano as well, but that's not where I see the time going. There are some differences between the NI SKUs which will require additional work on top of what has been done already, and we want to try and tie work on the next generation core into the proprietary development effort, which means we need to start *now* rather than a year from now.

    I think there will be free time but I don't expect it to come quickly. When the free time *does* come the issues you mentioned may not be top-of-mind any more.

    Doing more on the power management side will be a priority, whether we do it or the community devs do it. Dynpm may not be top priority either, those are the things we are trying to figure out now.

    Originally posted by HokTar View Post
    Anyway, if Alex or Richard will have some free time then my question will get answered, I guess.
    It's a pretty safe bet that they will have some free time, but because it may not happen for a while I just can't give any kind of confident answer that they will be working on the specific things you mentioned.

    Leave a comment:

Working...
X