Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: Marek Cleans-Up & Refactors R600g Driver

  1. #11
    Join Date
    Jul 2010
    Posts
    373

    Default

    Quote Originally Posted by jrch2k8 View Post
    hi, marek i have an stupid idea[that maybe can be good] since i don't have time to deal with learning gallium enough to implement opengl missing bits i was thinking that i should understand gallium enough to help optimizing the command stream but i was curious if exist a tool that let me, lets say run piglit and capture the CS from fglrx so i can compare it against r600g, maybe i can shoot some low hanging fruits in there.

    another thing i could spent my time with is comparing performance against a reference base[fglrx] but i wish to know if you know any utility that let me capture every gl call and see how much time needed to execute[not sure if can be possible with something like apitrace] dunno for example GL_ARB_Extension 200ms, ofc i don't expect to discover boiling water this way but it can provide a good start point to tackle some low hanging bottlenecks at least

    i do code optimization all day at work and i have lots of patience for it[Qt/C++ tho] but unlike cpu code im not sure if the gpu tools exist, so if the tooling i need exists[love if you can give the names so i can get them] and you can give me some starting points ill try my best in bot read the code
    You can use apitrace, "glretrace -p ..." for profiling. I've used it some time ago to compare mesa to windows catalyst. There was not much difference, just that SwapBuffers took like ten times longer with mesa/r600g if I remember correctly. But then my test code didn't do anything extraordinary, just setting textures and issuing draw calls most of the time.

  2. #12
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    733

    Default

    Ah, Marek fixes the world again.
    Kudos for the code cleanups. It makes things smoother.
    It's always good for all kinds of work if somebody else with some distance (or yourself with some time passed) goes over it and adds some polishing.

  3. #13
    Join Date
    Jun 2009
    Posts
    1,020

    Default

    Quote Originally Posted by log0 View Post
    You can use apitrace, "glretrace -p ..." for profiling. I've used it some time ago to compare mesa to windows catalyst. There was not much difference, just that SwapBuffers took like ten times longer with mesa/r600g if I remember correctly. But then my test code didn't do anything extraordinary, just setting textures and issuing draw calls most of the time.
    very useful thanks for your post, i think ill try with a common game like xonotic hoping to be able of reach some bottlenecks in a real world scenario[i suspect of some of the bottlenecks to be in shader and texture downloading but using this tooling you posted i think i can get some solid evidence and start from there again many thanks]

  4. #14
    Join Date
    Jan 2009
    Posts
    598

    Default

    Quote Originally Posted by jrch2k8 View Post
    hi, marek i have an stupid idea[that maybe can be good] since i don't have time to deal with learning gallium enough to implement opengl missing bits i was thinking that i should understand gallium enough to help optimizing the command stream but i was curious if exist a tool that let me, lets say run piglit and capture the CS from fglrx so i can compare it against r600g, maybe i can shoot some low hanging fruits in there.
    The tools exist, but Jerome has been doing that already and it doesn't seem to have borne much fruit (compared to the invested time). I was doing that too while working on r300g.

    Quote Originally Posted by jrch2k8 View Post
    another thing i could spent my time with is comparing performance against a reference base[fglrx] but i wish to know if you know any utility that let me capture every gl call and see how much time needed to execute[not sure if can be possible with something like apitrace] dunno for example GL_ARB_Extension 200ms, ofc i don't expect to discover boiling water this way but it can provide a good start point to tackle some low hanging bottlenecks at least
    Apitrace can capture GL calls, but the hardware executes commands in parallel, so you won't be able to tell how much time each command takes on the GPU. Besides that, Apitrace itself has huge CPU overhead and replaying commands with it is actually a lot slower, making it useless for benchmarking.

    Quote Originally Posted by Adarion View Post
    Kudos for the code cleanups. It makes things smoother.
    It's always good for all kinds of work if somebody else with some distance (or yourself with some time passed) goes over it and adds some polishing.
    The cleanups mainly ensure that the code doesn't turn into unmaintainable mess after a couple of years of development (and make supporting new features easier).

  5. #15
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,748

    Default

    Quote Originally Posted by marek View Post
    The cleanups mainly ensure that the code doesn't turn into unmaintainable mess after a couple of years of development (and make supporting new features easier).

    Hey Marek just curious, is there anything big you WISH you could do with R600g codebase? I've been following the posts about the Nouveau crowd rewriting the DRM bits, Intel rewriting how they do KMS, etc etc etc, and I was just curious: If you had infinite time to do it in, and would get paid to do it, whats the one thing you'd do to the R600g driver? Like are there any serious core design flaws that need to be fixed but that no one wants to/has the time, to fix?

    Edit: You can screw backwards compatibility with existing ABI/API if you have to
    Last edited by Ericg; 09-11-2012 at 01:55 PM.

  6. #16
    Join Date
    Jun 2009
    Posts
    1,020

    Default

    Quote Originally Posted by marek View Post
    The tools exist, but Jerome has been doing that already and it doesn't seem to have borne much fruit (compared to the invested time). I was doing that too while working on r300g.


    Apitrace can capture GL calls, but the hardware executes commands in parallel, so you won't be able to tell how much time each command takes on the GPU. Besides that, Apitrace itself has huge CPU overhead and replaying commands with it is actually a lot slower, making it useless for benchmarking.


    The cleanups mainly ensure that the code doesn't turn into unmaintainable mess after a couple of years of development (and make supporting new features easier).
    ok make sense but i guess since i got nights and weekends i can try anyway and maybe read lots of code to see if can find loops that can be unbranched or vectorized/threaded in the struct fest[more a c++ fan but i can get used to it]

  7. #17
    Join Date
    Jul 2010
    Posts
    373

    Default

    Quote Originally Posted by jrch2k8 View Post
    ok make sense but i guess since i got nights and weekends i can try anyway and maybe read lots of code to see if can find loops that can be unbranched or vectorized/threaded in the struct fest[more a c++ fan but i can get used to it]
    I think this is the profiling work mentioned by Marek, maybe interesting for you too.
    http://lists.freedesktop.org/archive...er/003998.html

  8. #18
    Join Date
    Jan 2009
    Posts
    598

    Default

    Quote Originally Posted by Ericg View Post
    Hey Marek just curious, is there anything big you WISH you could do with R600g codebase? I've been following the posts about the Nouveau crowd rewriting the DRM bits, Intel rewriting how they do KMS, etc etc etc, and I was just curious: If you had infinite time to do it in, and would get paid to do it, whats the one thing you'd do to the R600g driver? Like are there any serious core design flaws that need to be fixed but that no one wants to/has the time, to fix?
    Nothing big comes to my mind right now. R600g certainly needs a good optimizing compiler, it's the weakest spot of the driver. Most of the design flaws have been either fixed already or are in the process of being fixed.

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,748

    Default

    Quote Originally Posted by marek View Post
    or are in the process of being fixed.
    Anything big coming up that you know about? and thats good to hear there isnt anything major outstanding other than the compiler. Intel is my "go-to" right now just because my laptop is Sandy Bridge, but my Home theater is ATI (Fedora 17) based so I still keep up with R600g development.

    I know LLVM is being used for some parts of radeon but can it be used for that compiler too?

  10. #20
    Join Date
    Feb 2011
    Location
    France
    Posts
    164

    Default

    Jérome said, more than one year ago, that the kernel interface is quite bad and is (or will be) a bottleneck. But it's really hard to heavily modify this.

Posting Permissions

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