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

Thread: LLVMpipe's Geometry Processing Pipeline Kicks

  1. #11
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default

    Won't r300g utilize this for the parts of OpenGL 3 that require unimplemented functionality?

  2. #12
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,283

    Default

    AFAIK the main place this can affect hardware drivers is when running on integrated GPUs which don't have vertex processing (TCL) hardware, eg rs4xx and rs6xx. The previous software TCL code was *much* slower than the corresponding code in fglrx; this new code should bring that aspect of open source driver performance up to roughly fglrx levels.

    There were some problems running 300g on rs4xx/rs6xx parts in the past (ie it didn't work), not sure of current status so some additional work may be needed before this becomes usable on those IGP parts.

    re: OpenGL 3 and higher on 3xx-5xx parts, I'm not sure what the current thinking is. My expectation had been that only GL 2.x would be exposed (so the app would use code paths which were fully hardware implemented) but I don't know if anyone has looked hard at the implications of trying to run higher levels of GL on those parts.

  3. #13
    Join Date
    Oct 2008
    Posts
    2,909

    Default

    Quote Originally Posted by bridgman View Post
    AFAIK the main place this can affect hardware drivers is when running on integrated GPUs which don't have vertex processing (TCL) hardware, eg rs4xx and rs6xx.
    And intel chips, if they ever get gallium drivers running.

  4. #14
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default

    Can a state tracker use both hardware and softpipe?

  5. #15
    Join Date
    Oct 2008
    Posts
    2,909

    Default

    I believe the core functions of this code was added to a shared module that both the softpipe and hardware drivers can access. So it's not so much that both the hardware and softpipe are being used at the same time, but rather just a shared piece of code that any driver, including softpipe, can access.

  6. #16
    Join Date
    Nov 2008
    Posts
    755

    Default

    Quote Originally Posted by wswartzendruber View Post
    Can a state tracker use both hardware and softpipe?
    yes, but you have to be very careful to avoid buffer-ping-pong. When the CPU draws something, the data has to be moved to main memory, when the GPU draws something, it has to be moved back to video memory. Those moves are slooooow.

    The rendering pipeline looks something like this (oversimplified):

    openGL-call -> geometry shaders -> vertex shaders -> pixel shaders -> final image

    On a modern GPU, the red stage is done on the CPU, everything after that on the GPU. You can shift the early phases to the CPU, but alternating between CPU and GPU-calculations kills performance - it may end up slower than doing full software-rendering.

  7. #17
    Join Date
    Jan 2009
    Posts
    274

    Default

    Quote Originally Posted by rohcQaH View Post
    yes, but you have to be very careful to avoid buffer-ping-pong. When the CPU draws something, the data has to be moved to main memory, when the GPU draws something, it has to be moved back to video memory. Those moves are slooooow.

    The rendering pipeline looks something like this (oversimplified):

    openGL-call -> geometry shaders -> vertex shaders -> pixel shaders -> final image

    On a modern GPU, the red stage is done on the CPU, everything after that on the GPU. You can shift the early phases to the CPU, but alternating between CPU and GPU-calculations kills performance - it may end up slower than doing full software-rendering.
    That would be very true for AGP I don't know how bad it would be on PCI-E though... theres a lot more bandwidth to work with also can the cpu directly map PCI-E or does it have to copy things from buffers as you say

  8. #18
    Join Date
    Oct 2008
    Posts
    2,909

    Default

    I'm pretty sure the CPU has to copy everything into main memory before it can operate on it. And the problem isn't bandwidth, which there is plenty of, but latency. Just like seek times kill performance on HDDs even when you're getting small files that don't saturate the bandwidth.

  9. #19
    Join Date
    Nov 2008
    Posts
    755

    Default

    bandwidth isn't the problem, latency and synchronisation is. While the buffer is being copied around, neither the GPU nor the CPU can work on it, everything stalls.

    That's no problem when it's done a few times per frame, but it can get really bothersome if you do it in the later stages of the pipeline where you may need a buffer-copy for every object or even every triangle you're drawing.


    edit: oh, I shouldn't go afk for an hour between writing and submitting a post

  10. #20
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    392

    Default

    Wasn't LLVM also planned to be used to compile/optimize/generate shader code for specific GPUs? Or is that something entirely different?

Posting Permissions

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