Announcement

Collapse
No announcement yet.

NVIDIA, Red Hat Partner Up For New Graphics Project

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

  • NVIDIA, Red Hat Partner Up For New Graphics Project

    Phoronix: NVIDIA, Red Hat Partner Up For New Graphics Project

    Jerome Glisse has long been involved with open-source Linux graphics drivers, but in recent months he hasn't announced any major breakthroughs like in past years. However, at Red Hat they have struck up a partnership with NVIDIA to work on a new device-agnostic API for the Linux kernel that can benefit the graphics drivers...

    http://www.phoronix.com/vr.php?view=MTQ3MTY

  • #2
    here is the video:
    https://www.youtube.com/watch?v=X3M9A8TT1dg

    Comment


    • #3
      I smell answer to Mantle. Since Nvidia cannot successfully set new API standard on the consumer front, due to AMD control of the console market, so they went for the enterprise. =)

      Hopefully we come out with some nice new API after all that and not...



      ... has they did suck when it came to GPU.

      Comment


      • #4
        Michael, I uploaded the videos 12 hours ago on youtube and updated the pages. However, for some strange reason, the web server doesn't implement caching properly so you may need to press F5.

        Anyway, the videos for this talk are available at: http://www.x.org/wiki/Events/XDC2013...dressSpaceGPU/

        Comment


        • #5
          Originally posted by iniudan View Post
          I smell answer to Mantle. Since Nvidia cannot successfully set new API standard on the consumer front, due to AMD control of the console market, so they went for the enterprise. =)

          Hopefully we come out with some nice new API after all that and not...

          ... has they did suck when it came to GPU.
          This is more to do w/ compute.. not even vaguely related to mantle. It is something that could be used by newer amd or nv gpus. It is not an application facing API, but rather kernel infrastructure to allow GPU and CPU to share address space (which could be used to implement opencl extension, etc).

          If gallium decided to make the API used by state trackers as a stable ABI, and exported it so that game developers could use it directly, that would be something a bit more equivalent to mantle.

          Comment


          • #6
            Originally posted by robclark View Post
            This is more to do w/ compute.. not even vaguely related to mantle. It is something that could be used by newer amd or nv gpus. It is not an application facing API, but rather kernel infrastructure to allow GPU and CPU to share address space (which could be used to implement opencl extension, etc).

            If gallium decided to make the API used by state trackers as a stable ABI, and exported it so that game developers could use it directly, that would be something a bit more equivalent to mantle.
            I am not saying it is equivalent to Mantle, just saying it is an answer to it, has creating open API standard, let you be ahead of the competition, without damaging possibility of generalized adoption, has you have internal knowledge of the development, letting you better plan a road map, has to optimize for said API.

            Comment


            • #7
              Originally posted by robclark View Post
              It is not an application facing API, but rather kernel infrastructure to allow GPU and CPU to share address space (which could be used to implement opencl extension, etc).
              Rob forgive me if I took your response a step too far, but it was the first thing that popped in my head when you said this...

              So its a kernelside answer from Nvidia(and probably Intel) to AMD's HSA?

              AMD+AMD you get HSA, Nvidia+Intel you get this kernelside API? Or could AMD HSA be implemented using this kernel side API? (Im not sure how much HSA is done in hardware vs software)

              I'm all for this project, it SOUNDS like a good project, I'm just trying to figure out where in the landscape it falls given AMD's HSA work which sounds very similar.

              Comment


              • #8
                this also looks to remove a ton of over head seeing how its going to move even more code into the kernel also i see this adding better PRIME support

                Comment


                • #9
                  Originally posted by Ericg View Post
                  Rob forgive me if I took your response a step too far, but it was the first thing that popped in my head when you said this...

                  So its a kernelside answer from Nvidia(and probably Intel) to AMD's HSA?

                  AMD+AMD you get HSA, Nvidia+Intel you get this kernelside API? Or could AMD HSA be implemented using this kernel side API? (Im not sure how much HSA is done in hardware vs software)

                  I'm all for this project, it SOUNDS like a good project, I'm just trying to figure out where in the landscape it falls given AMD's HSA work which sounds very similar.
                  We both might be wrong but I understood it the same way you did with the possible difference that I'm not sure amd's HSA is so much an api as a standard hardware configuration. It seemed as if the work would be handled in software with the drivers making the decisions. Maybe to get that working requires some new kernel features?

                  Comment


                  • #10
                    Originally posted by liam View Post
                    We both might be wrong but I understood it the same way you did with the possible difference that I'm not sure amd's HSA is so much an api as a standard hardware configuration. It seemed as if the work would be handled in software with the drivers making the decisions. Maybe to get that working requires some new kernel features?
                    Well, as I understand it, maybe calling it a hw solution vs sw solution is a bit of a misnomer.. as they both require some hw and some sw to make it work. So maybe the AMD solution is the *more* hw solution.

                    At any rate, the patchset that Jerome is working on is intended to provide what would be needed for both AMD and NV.

                    Comment


                    • #11
                      Originally posted by robclark View Post
                      Well, as I understand it, maybe calling it a hw solution vs sw solution is a bit of a misnomer.. as they both require some hw and some sw to make it work. So maybe the AMD solution is the *more* hw solution.

                      At any rate, the patchset that Jerome is working on is intended to provide what would be needed for both AMD and NV.
                      Hmm, I was a bit uncertain about that do thanks for your insights.
                      BTW, did you ever receive my pm?

                      Comment


                      • #12
                        Can someone explain to me how this whole "no copy" thing even works? I mean for the GPU to operate on data, it has to be resident in VRAM right?
                        How can you circumvent a copy if this RAM -> VRAM transfer is still there? Does the GPU read directly from RAM?

                        Comment


                        • #13
                          Originally posted by Ancurio View Post
                          Can someone explain to me how this whole "no copy" thing even works? I mean for the GPU to operate on data, it has to be resident in VRAM right?
                          How can you circumvent a copy if this RAM -> VRAM transfer is still there? Does the GPU read directly from RAM?
                          Yes, the GPU can read the CPU address space.

                          Comment


                          • #14
                            Originally posted by MPF View Post
                            Yes, the GPU can read the CPU address space.
                            So, basically, we don't need glTexImage anymore?

                            Comment


                            • #15
                              Originally posted by Ancurio View Post
                              So, basically, we don't need glTexImage anymore?
                              well, the gpu is still not synchronous, but the symantics of glTexImage are synchronous. So you either need a copy there, or some GL extension that lets the driver hold on to those pages until some time after.

                              Also, frequently drivers will convert the texture into some internal tiled format for better memory access efficiency. Which at least makes sense if you are going to use the texture multiple times.

                              Comment

                              Working...
                              X