Announcement

Collapse
No announcement yet.

Marek Cleans-Up & Refactors R600g Driver

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

  • #16
    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]

    Comment


    • #17
      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

      Comment


      • #18
        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.

        Comment


        • #19
          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?

          Comment


          • #20
            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.

            Comment


            • #21
              Originally posted by log0 View Post
              I think this is the profiling work mentioned by Marek, maybe interesting for you too.
              http://lists.freedesktop.org/archive...er/003998.html
              again very useful, i have hope that using apitrace/oprofile/CS cross check i can find some bottlenecks and maybe playing a bit with tom stellard llvm compiler[won't be easy tho but should be a good way to get more intimate with gallium code ]

              Comment


              • #22
                Originally posted by whitecat View Post
                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.
                I think the kernel interface is quite good. Jerome just likes to rewrite things from scratch. It's a sport for him. Most of the kernel code is executed in another thread and runs in parallel with Mesa most of the time. You wouldn't probably even notice if the kernel code were twice as slow.

                Comment


                • #23
                  Support Marek

                  A great think to help Marek is to buy him a beer or two. In his account you have his paypal address.

                  Marek, you already have my 20€ of thanks.

                  Comment


                  • #24
                    Originally posted by marek View Post
                    I think the kernel interface is quite good. Jerome just likes to rewrite things from scratch. It's a sport for him. Most of the kernel code is executed in another thread and runs in parallel with Mesa most of the time. You wouldn't probably even notice if the kernel code were twice as slow.
                    So, would it become a concern if we had open source crossfire/sli support?

                    Comment


                    • #25
                      Originally posted by Almorca View Post
                      A great think to help Marek is to buy him a beer or two. In his account you have his paypal address.

                      Marek, you already have my 20€ of thanks.
                      THANKS! Thats very nice!

                      I need just to wait till cards stabilize more, then he has 50€ from me! However, this will happen unless Intel makes powerful GPU. In this case, it will be a hard decision!

                      Comment


                      • #26
                        Originally posted by crazycheese View Post
                        THANKS! Thats very nice!

                        I need just to wait till cards stabilize more, then he has 50€ from me! However, this will happen unless Intel makes powerful GPU. In this case, it will be a hard decision!
                        Good work is good work. And Marek is doing it. He has 20€ from me.
                        I have one question. Marek, after you finish r600g re-factoring what is next? Do you have the will to optimize r600g shader compiler? If yes, will you be using LLVM back-end for this endeavor?

                        Comment


                        • #27
                          Originally posted by liam View Post
                          So, would it become a concern if we had open source crossfire/sli support?
                          I think it's too early to talk about crossfire. We are not even on par with fglrx on single-card configurations as far as features and performance are concerned. The thing with the R300-R500 GPUs was that Catalyst 9.3 hadn't seemed to be as much optimized as it is now, so it wasn't so hard to outperform it in some tests. It's going to be much harder to compete with todays fglrx on R600 and later hardware.

                          Originally posted by Drago View Post
                          I have one question. Marek, after you finish r600g re-factoring what is next? Do you have the will to optimize r600g shader compiler? If yes, will you be using LLVM back-end for this endeavor?
                          OpenGL 3.1 support and bug fixes are on the top of my lists right now. OpenGL 3.1 shouldn't be so hard, because there is core Mesa support in place already.

                          Comment


                          • #28
                            Originally posted by marek View Post
                            OpenGL 3.1 support and bug fixes are on the top of my lists right now. OpenGL 3.1 shouldn't be so hard, because there is core Mesa support in place already.
                            Marek, it would be just outrageous, if you guys fix the card bottleneck. Rise the performance to at least 60% compared to catalyst, where possible before moving further. This will justify people to use and purchase AMD cards for your driver. There is little sense widening OpenGL support if barely anyone can use this fruit on AMD cards. You work will just spread out to other chips, that have already that bottlenecking solved. Please!

                            Comment


                            • #29
                              Originally posted by crazycheese View Post
                              Marek, it would be just outrageous, if you guys fix the card bottleneck. Rise the performance to at least 60% compared to catalyst, where possible before moving further. This will justify people to use and purchase AMD cards for your driver. There is little sense widening OpenGL support if barely anyone can use this fruit on AMD cards. You work will just spread out to other chips, that have already that bottlenecking solved. Please!
                              Second that. Most games run with this level of OpenGL support, but too slow. Especially on the APU front.

                              Comment


                              • #30
                                If you have the latest Mesa and DDX, try to enable 2D tiling in xorg.conf. It should give you a nice boost in bandwidth-limited apps.

                                Comment

                                Working...
                                X