Announcement

Collapse
No announcement yet.

LLVMpipe Still Is Slow At Running OpenGL On The CPU

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

  • #16
    Originally posted by bridgman View Post
    Sure, you just turn on the "magic pixie dust" bit in the hardware

    Seriously, dealing with latency between different memory subsystems (with the associated need for change detection and synchronization) is probably the biggest single challenge when implementing highly parallel systems. It doesn't mean that an easy solution does not exist but it hasn't been found yet.

    Read up on "cache snooping", for example.
    Oh yeah... that shit...

    OK first you need to have two adress maps which do not match so they both have to know what adress of a copy of what adres matches with a tag.

    Then both the CPU and the GPU must never at the same time write to the same thing at the same time, while you cannot work with each other (great) so one of the two needs to be the dominant desicion maker. That would be the CPU as it can execute a driver for the graphics card.

    So then the CPU will put what's about to be modified in a command buffer (sort of) and then check what the GPU can alter at that time that does not correspond to the CPU's adress tags changes. Then wen both buffers are empty the lock on what can't be done by the GPU that the CPU keeps track of is lifted and then the GPU can continue.

    Either way massive latency hell...

    Comment


    • #17
      Welcome to driver development

      Comment


      • #18
        Dynamic load balancing, we already have that, it's called SLI

        Comment


        • #19
          SLI (and Crossfire) might do dynamic load balancing between GPUs, but this is something different - dynamic load balancing between CPU and GPU.

          Comment


          • #20
            Originally posted by bridgman View Post
            SLI (and Crossfire) might do dynamic load balancing between GPUs, but this is something different - dynamic load balancing between CPU and GPU.
            Not worth it unless you have a CPU that is -really- good at graphics rendering. A good example of this is the PS3- even the RSX with a weak fill rate can deliver stunning visuals with the Cell's SPUs working on parts of the graphics load. This is largely thanks to the combination of XDR and DDR3- low latency XDR doesn't have the peak raw bandwidth of DDR3, but can be randomly accessed by the GPU without taking too many memory cycles away from the CPU- allowing communication and load distribution to work really smoothly (if done right, of course).

            x86(_64) on the other hand is not really good at this and chipset hardware was never designed for ultra-low-latency or high-bandwidth communication between the CPU and GPU. The CPU would better be put to work on physics in most 4-8 core scenarios.

            Comment


            • #21
              It's a bit like video rendering - anything which requires data transfer back and forth kills performance, but you can sometimes keep things on the CPU a bit further down the pipe before transferring to the GPU and executing the rest of the pipeline on the GPU.

              It's unlikely that you would ever want to do pixel rendering on CPU if you had any kind of GPU available, but CPUs can be pretty good at vertex processing. The classic scenario for this is a high end CPU paired with IGP, which is not that unusual.

              Comment


              • #22
                But how does Fusion affect this? There's a damn direct, short copper line straight between the two, they use the same ram..

                Comment


                • #23
                  Originally posted by curaga View Post
                  But how does Fusion affect this? There's a damn direct, short copper line straight between the two, they use the same ram..
                  That is **EXACTLY** the same thing I was thinking about.
                  And correct me if I'm wrong, but isn't that the WHOLE POINT of Fusion/APU's?

                  Comment


                  • #24
                    I am very excited about this fusion stuff. Am I correct in my analysis that this can create some quite powerful small devices? Think graphics power comparing to top of the line GPU's now along with some nice strong CPU all in an mini-ITX form factor. Actually being able to play decent games on a tiny media center running linux

                    Comment


                    • #25
                      I read somewhere that the first fusion cpus will have graphics comparable to HD5450, low-end r800. Will improve later, hopefully.

                      Comment


                      • #26
                        Well, fusion doesn't magically solve the heat problem. Try cramming a high-end 6-core and a 5890 into a single package, then try keeping it cool without liquid nitrogen. Doesn't work so well.

                        There will be several fusion chips with different tradeoffs between CPU and GPU power. It'd make sense to start with the models with low-end GPUs: it's enough for office work and HTPCs (assuming UVD works), so it's probably the configuration that's expected to sell best. More models can be delivered later to suit different needs.

                        Comment


                        • #27
                          Originally posted by rohcQaH View Post
                          Well, fusion doesn't magically solve the heat problem.
                          Not to mention it shares the same serial access memory and does the Fusion CPU also get its own framebuffer, crtc and port connectors, or... ? Because in that case you still have to have a seperate (partial) VGA and so it would only benifit OpenCL(-ish stuff) (for now).

                          Comment


                          • #28
                            Originally posted by FunkyRider View Post
                            Dynamic load balancing, we already have that, it's called SLI
                            No, this is a smidge different and hasn't even really been done yet. Larabee MIGHT have brought the start of that sort of thing to the picture, but sadly it's not going to be hitting the market as a discrete GPU, now is it?

                            Comment


                            • #29
                              what about including Intel IGP ?

                              Originally posted by jrch2k8 View Post
                              ... in any case compare it against an intel crappy igp

                              btw push 28 fps cpu only is quite an achievement
                              I think it could be interesting to compare this software driver with an intel IGP as it may be the #1 client for this kind of driver.
                              I personnally own a 9800 GT and will never think about using this software driver (and for any Nvidia/Ati solution); but on M/B with intel integrated video, for me, it make sense to compare it with any kind of intel dedicated drivers (open/closed source) or other software solution like Mesa.

                              Hope it will come with the next Mesa soft. vs LLVMpipe bench.

                              Comment


                              • #30
                                Yes Intel IGP is already done as part of next comparison. Mesa Software Rasterizer was thrown out though since it can't break 1FPS.
                                Michael Larabel
                                http://www.michaellarabel.com/

                                Comment

                                Working...
                                X