Announcement

Collapse
No announcement yet.

The OpenCL State Tracker Nears Working State

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

  • The OpenCL State Tracker Nears Working State

    Phoronix: The OpenCL State Tracker Nears Working State

    There's an update to the ongoing X.Org Endless Vacation of Code work, which is currently funding a developer to work on the OpenCL upbringing within the open-source world for graphics drivers. The latest work going on has been redesigning and largely rewriting the Clover state tracker that will provide the OpenCL support to Gallium3D graphics drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    If you want to hear more about Francisco's OpenCL work...

    Comment


    • #3
      Does anyone know if video of this talk is being captured, or if the lecture notes/slides (if any) are publicly available? I wish I could be there.

      Comment


      • #4
        Originally posted by Veerappan View Post
        Does anyone know if video of this talk is being captured, or if the lecture notes/slides (if any) are publicly available? I wish I could be there.

        Yes I plan to do it again.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          With Francisco's and Tom's work, will it be possible to run OpenCL programs on both my graphics cards with this state tracker and the open source driver? Or would you need crossfire do to this? AFAIK, I thought crossfire was more of sharing a graphics load and not a compute load.

          Comment


          • #6
            Originally posted by FourDMusic View Post
            With Francisco's and Tom's work, will it be possible to run OpenCL programs on both my graphics cards with this state tracker and the open source driver? Or would you need crossfire do to this? AFAIK, I thought crossfire was more of sharing a graphics load and not a compute load.
            Crossfire is about splitting a single graphics load then recombining the results into a single framebuffer so you wouldn't need it for OpenCL. Whether or not the first working implementation will support multiple GPUs for compute is another question and one of the devs working on it would have to answer.

            AFAIK the OpenCL support for multiple devices uses an "expose both devices to the application and let it decide what to do" model rather than "pretend to be a single device and invisibly split/reassemble the work" so support for multiple devices with OpenCL should be a lot less work than a full Crossfire implementation.
            Last edited by bridgman; 28 January 2012, 11:33 AM.
            Test signature

            Comment


            • #7
              So, how does this fit in with the work that AMD is doing to support OpenCL through LLVM? Will there be two seperate OpenCL state trackers - one that emits LLVM, and another that emits TGSI?

              On a related note - LLVM has already started to support VLIW with the MachineInstrBundle, and they say there will be a generic VLIW scheduler in the future - so my 2 cents is that LLVM is looking better and better as a GPU IR. So, what exactly is missing from the backend then to prevent everybody from just switching over now? Are there some vector instructions missing?

              Comment


              • #8
                Originally posted by cwabbott View Post
                So, how does this fit in with the work that AMD is doing to support OpenCL through LLVM? Will there be two seperate OpenCL state trackers - one that emits LLVM, and another that emits TGSI?
                The clang front end generates LLVM IR and clover was written around LLVM IR (it used LLVM to generate x86 code to run the OpenCL kernels). I don't know if Francisco kept all the LLVM to x86 functionality but if not I guess we'll need to hook into the LLVM IR before it gets converted to TGSI. Tom was planning to go through Gallium3D but with a flag to pass LLVM rather than TGSI so hopefully they're heading in the same direction plus or minus a flag setting anyways.

                We could go c99 => LLVM IR => TGSI => LLVM IR => ISA rather than C99 => LLVM IR => ISA but that seems like something we should avoid if possible.
                Last edited by bridgman; 29 January 2012, 12:26 AM.
                Test signature

                Comment


                • #9
                  Originally posted by bridgman View Post
                  The clang front end generates LLVM IR and clover was written around LLVM IR (it used LLVM to generate x86 code to run the OpenCL kernels). I don't know if Francisco kept all the LLVM to x86 functionality but if not I guess we'll need to hook into the LLVM IR before it gets converted to TGSI. Tom and Francisco talk frequently so hopefully one isn't demolishing what the other is building on.

                  We could go c99 => LLVM IR => TGSI => LLVM IR => ISA rather than C99 => LLVM IR => ISA but that seems like something we should avoid if possible.
                  So, I'll ask a question from a different perspective - what IR would you recommend for someone who was starting from scratch on a new driver? All LLVM, LLVM for compute and TGSI for graphics, or all TGSI? Would it be more work re-implementing optimizations/features already in LLVM, or adding needed functionality to LLVM?

                  Comment


                  • #10
                    Is the hardware scalar, vector or VLIW ?
                    Test signature

                    Comment

                    Working...
                    X