Page 14 of 17 FirstFirst ... 41213141516 ... LastLast
Results 131 to 140 of 164

Thread: Benchmarks Of AMD's Newest Gallium3D Driver

  1. #131
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    Quote Originally Posted by HokTar View Post
    Anyway, I suspect that having good h264 decoding possibilities and an efficient dynpm would significantly reduce the whining and the "what if" comments. Opengl and cl would still remain but we could have a good everyday driver. Are these on your short-term list? Maybe even helping out Christian Konig. Well, one can dream, I guess.
    Top priority for the AMD devs is enabling support for new GPU generations (via code and/or docs) and supporting community devs, which are the things that pretty much have to be done in house. When time permits, the devs also work on improving existing support (Alex wrote the initial EXA and Textured Video code, along with initial power management and a bunch of other things, Richard added GLSL and flow control support) but only when time permits.

    Other than not being enabled by default, are you seeing problems with dynpm ? My recollection was that the "glitching" issue was largely fixed a month or two ago, and the remaining TODO task (splitting the code so that memory and engine clocks are changed in different blanking periods) could be done by anyone.

  2. #132
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by bridgman View Post
    Top priority for the AMD devs is enabling support for new GPU generations (via code and/or docs) and supporting community devs, which are the things that pretty much have to be done in house. When time permits, the devs also work on improving existing support (Alex wrote the initial EXA and Textured Video code, along with initial power management and a bunch of other things, Richard added GLSL and flow control support) but only when time permits.

    Other than not being enabled by default, are you seeing problems with dynpm ? My recollection was that the "glitching" issue was largely fixed a month or two ago, and the remaining TODO task (splitting the code so that memory and engine clocks are changed in different blanking periods) could be done by anyone.
    Whenever I tried it did not lowered the clock/voltage. Manually setting it to low works fine.

    I think I have a fairly good understanding of the current methodology, i.e. you enable drivers than the community enhances it. I dared to ask that question because it seems that only the NI chips are left and the desktop APU is still far away. So my thinking was that in the next few months you might have some free time to help out here and there. Maybe I am completely wrong.

  3. #133
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    Nope, you're right... although if we're going to stay "caught up" there's not going to be a *lot* of free time between generations.

  4. #134
    Join Date
    Jul 2007
    Posts
    440

    Default Can you elaborate on this glitching issue, please?

    Quote Originally Posted by bridgman View Post
    Other than not being enabled by default, are you seeing problems with dynpm ? My recollection was that the "glitching" issue was largely fixed a month or two ago...
    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).

  5. #135
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by bridgman View Post
    Nope, you're right... although if we're going to stay "caught up" there's not going to be a *lot* of free time between generations.
    Sometimes you show your admirable skill in not answering a question. Not to mention that I never said "a lot".

    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.

    Anyway, if Alex or Richard will have some free time then my question will get answered, I guess.

  6. #136
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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.

  7. #137
    Join Date
    Dec 2009
    Posts
    338

    Default

    Fair enough. Thanks.

  8. #138
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    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"

  9. #139
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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 ....

  10. #140
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

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