Announcement

Collapse
No announcement yet.

AMD Releases Open-Source UVD Video Support

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

  • Originally posted by artivision View Post
    I cannot except that. You say that i can't have my own compiler for a GPU, because the GPU will not accept to execute the produced machinery code?
    another thing is not having a compiler the issue is keeping it in a way the driver knows what to do with it, so for this the driver have to understand HLSL and basic DX so it actually knows that this shader have to be applied on X and Y condition over that object Z.z and the result should reside in X,Y framebuffer memory if it will be reused for example.

    if you simply send a bunch of byte code with the rest of the control code[be gl or DX] GPU will just hardlock, GPU are DUMB and very unfriendly to work with

    Comment


    • Originally posted by jrch2k8 View Post
      another thing is not having a compiler the issue is keeping it in a way the driver knows what to do with it, so for this the driver have to understand HLSL and basic DX so it actually knows that this shader have to be applied on X and Y condition over that object Z.z and the result should reside in X,Y framebuffer memory if it will be reused for example.

      if you simply send a bunch of byte code with the rest of the control code[be gl or DX] GPU will just hardlock, GPU are DUMB and very unfriendly to work with

      Mesa compiler can pass machinery_code to the GPU. The same(modified) path can be used for an HLSL_compiler. The target libraries(for MS_D3D) are there inside Windows drivers. The GPU driver is unified for DirectX and OpenGL(at least with some vendors), that includes execution programs, draw graphics, FX processor. Are you sure if one try, will fail???

      Comment


      • Originally posted by artivision View Post
        Mesa compiler can pass machinery_code to the GPU. The same(modified) path can be used for an HLSL_compiler. The target libraries(for MS_D3D) are there inside Windows drivers. The GPU driver is unified for DirectX and OpenGL(at least with some vendors), that includes execution programs, draw graphics, FX processor. Are you sure if one try, will fail???
        it will fail depending how you do it.

        1.) is not a problem of machinery code is a problem of relation, like glsl need EGL/Wgl/Xgl/Agl/etc and Opengl to be able to understand GLSL you need DX[or a translation layer to opengl] too otherwise the GPU will lock
        2.) the directx code is not runnable on linux at all, is very specifically tied to use windows only code and kernel calls, so either nVidia or AMD will need to rewrite the entire DX codepath to use the Linux only code[which will require more code since both kernel model are quite different] with DX too, remember when you write an opengl driver it has to be portable but with directx you don't need to since only windows use it.

        so you can make a linux driver understand DX? yes and compile DX? yes but is not as simple as you think and require a lot of code. for example you can modify the r600g llvm backend to process HLSL and reuse the DX gallium state tracker and try to complete it and get in contact with the kernel folks to modify KMS and DRM modules accordingly and after that you need to convince AMD and nVidia to do the same in their closed counterparts so the driver from linux can access their directx codepaths.

        the point been, is not as simple as dump hlsl machinery code and expect it would render

        Comment


        • Originally posted by Adarion View Post
          JAWOHL!!

          Sorry for this German outbreak of Yeeeeah! This is something I have waited for so long. It actually so rescued my day! The whole week! Even more!
          Thanks!
          And thanks also for using VDPAU. There is just much more support for it.

          Hope that the old UVD 1 will also see some love.

          I am so happy that I do not drink alcohol at all, otherwise I'd probably kill me with sparkling wine today!


          So when are you fixing your signature again? I miss a fellow AMD Fanboy

          Comment


          • This is great news. I hope I can some day buy a low power / fanless Radeon to complement my Core i3 (first gen) and get much better 3D performance without having to buy a whole new computer.

            Comment


            • Originally posted by jrch2k8 View Post
              it will fail depending how you do it.

              1.) is not a problem of machinery code is a problem of relation, like glsl need EGL/Wgl/Xgl/Agl/etc and Opengl to be able to understand GLSL you need DX[or a translation layer to opengl] too otherwise the GPU will lock
              2.) the directx code is not runnable on linux at all, is very specifically tied to use windows only code and kernel calls, so either nVidia or AMD will need to rewrite the entire DX codepath to use the Linux only code[which will require more code since both kernel model are quite different] with DX too, remember when you write an opengl driver it has to be portable but with directx you don't need to since only windows use it.

              so you can make a linux driver understand DX? yes and compile DX? yes but is not as simple as you think and require a lot of code. for example you can modify the r600g llvm backend to process HLSL and reuse the DX gallium state tracker and try to complete it and get in contact with the kernel folks to modify KMS and DRM modules accordingly and after that you need to convince AMD and nVidia to do the same in their closed counterparts so the driver from linux can access their directx codepaths.

              the point been, is not as simple as dump hlsl machinery code and expect it would render


              What do you mean "the directx code is not runnable on linux at all". I can run it via Wine, even if i need vcrun. Then i can give it a target library, extracted from Windows drivers. So then maybe the produced machinery code can be loaded to the Linux closed driver.

              Comment


              • Originally posted by artivision View Post
                Wine doesn't emulate any GPU driver functionality. It just translates HLSL bytecode to GLSL. I can also call you a liar, because some months before, you post to a comment of mine, that your driver is unified for D3D and OGL, and the same quality as your competitor. You probably don't know ether.
                Can you point me to that post please ? In every post I could find I said that the D3D and GL drivers were separate. They share the back end shader compiler (AMDIL to HW instructions) but the driver and front-end compilers (GLSL to AMDIL, HLSL to AMDIL) are different and independent.

                http://phoronix.com/forums/showthrea...730#post311730

                http://phoronix.com/forums/showthrea...272#post311272

                http://phoronix.com/forums/showthrea...765#post311765

                Comment


                • Originally posted by artivision View Post
                  What do you mean "the directx code is not runnable on linux at all". I can run it via Wine, even if i need vcrun. Then i can give it a target library, extracted from Windows drivers. So then maybe the produced machinery code can be loaded to the Linux closed driver.
                  the problem is wine don't have a window driver and the DirectX libraries are not drivers but generic protocol libraries that define an API over the WDDM API, inside windows you have another set of libraries that include kernel/middleware/userspace driver code that is provided by your manufacturer[nVidia/AMD/Via] that actually defines the WDDM API to hardware code and that is where the actual compiler and libd3d are not in the microsoft package of DirectX and is not possible for wine to emulate those drivers since are extremely tied to the NT kernel.

                  what wine does is sorta like defining the underlying WDDM[but DX9 era] with virtual hardware that instead of go to metal convert it to Opengl Calls for which it actually have drivers.

                  what i mean with "the directx code is not runnable on linux at all"[add the below too] is that common code drivers are like this:

                  virtual function XyzGraphicOperationLowLevel(arg 1, arg2, arg3, customTypeA, OriginConditionalA){
                  //OS agnostic C/C++/gpu code
                  }

                  function ActualDirectXCall(arg 1, arg2, arg3){//Symbol hidden/removed on other OS except for windows
                  //Windows only Win32 API/WDDM
                  XyzGraphicOperationLowLevel(arg 1, arg2, arg3, Ver11, isDirectX);
                  //Directx specific code or minor differences
                  }

                  function ActualOpenglCall(arg 1, arg2, arg3){//Symbol available in any OS
                  //Windows only Win32 API/WDDM and Linux specific
                  XyzGraphicOperationLowLevel(arg 1, arg2, arg3, Ver43, isGLX);
                  //opengl specific code or minor differences
                  }

                  so both DirectX and OpenGL use XyzGraphicOperationLowLevel[shared code] and that function is on any driver regardless the OS but ActualDirectXCall[specialized Code] is only available with a windows OS driver but ActualOpenglCall[specialized Code] is available everywhere, the problem as you see is that ActualDirectXCall uses Windows specific API and need to be rewritten to support Posix API too and make the symbol available in Linux which may require many changes at kernel level API since linux and NT handle things very differently

                  i hope is more clear now

                  Comment


                  • Originally posted by agd5f View Post
                    Not sure exactly what you are asking. ruvd contains the common UVD code that's shared by r600 and radeonsi.
                    I may be misunderstanding things, so bear with me
                    From looking at mesa, you've added ruvd as a new driver. Now, my question is why.
                    I understand wanting to share code, of course, but wondered why creating a new driver was the way to go.
                    http://cgit.freedesktop.org/mesa/mes...allium/drivers
                    Thus far, the other drivers seem to be focused on complete devices (even if virtual), not subsets of device functionality.

                    I'm sure I'm missing something here...

                    Comment


                    • Originally posted by liam View Post
                      I may be misunderstanding things, so bear with me
                      From looking at mesa, you've added ruvd as a new driver. Now, my question is why.
                      I understand wanting to share code, of course, but wondered why creating a new driver was the way to go.
                      http://cgit.freedesktop.org/mesa/mes...allium/drivers
                      Thus far, the other drivers seem to be focused on complete devices (even if virtual), not subsets of device functionality.

                      I'm sure I'm missing something here...
                      That's not entirely true. There's already a radeon folder in mesa/mesa/tree/src/gallium/drivers that has shared llvm code (for r600 and radeonsi). v2 of Christian's UVD patch adds the uvd code to that directory. The same code is used for two drivers (r600 and radeonsi) so it lives in it's own directory. Storing the files in both radeonsi and r600 would duplicate code and we'd need to update two sets of code if we made any changes.

                      Comment


                      • Originally posted by agd5f View Post
                        That's not entirely true. There's already a radeon folder in mesa/mesa/tree/src/gallium/drivers that has shared llvm code (for r600 and radeonsi). v2 of Christian's UVD patch adds the uvd code to that directory. The same code is used for two drivers (r600 and radeonsi) so it lives in it's own directory. Storing the files in both radeonsi and r600 would duplicate code and we'd need to update two sets of code if we made any changes.
                        Ah, so radeon and ruvd are for code sharing convenience, and are brought brought in when built.
                        Thanks for the explanation!

                        Best/Liam

                        Comment


                        • Originally posted by jrch2k8 View Post
                          the problem is wine don't have a window driver and the DirectX libraries are not drivers but generic protocol libraries that define an API over the WDDM API, inside windows you have another set of libraries that include kernel/middleware/userspace driver code that is provided by your manufacturer[nVidia/AMD/Via] that actually defines the WDDM API to hardware code and that is where the actual compiler and libd3d are not in the microsoft package of DirectX and is not possible for wine to emulate those drivers since are extremely tied to the NT kernel.

                          what wine does is sorta like defining the underlying WDDM[but DX9 era] with virtual hardware that instead of go to metal convert it to Opengl Calls for which it actually have drivers.

                          what i mean with "the directx code is not runnable on linux at all"[add the below too] is that common code drivers are like this:

                          virtual function XyzGraphicOperationLowLevel(arg 1, arg2, arg3, customTypeA, OriginConditionalA){
                          //OS agnostic C/C++/gpu code
                          }

                          function ActualDirectXCall(arg 1, arg2, arg3){//Symbol hidden/removed on other OS except for windows
                          //Windows only Win32 API/WDDM
                          XyzGraphicOperationLowLevel(arg 1, arg2, arg3, Ver11, isDirectX);
                          //Directx specific code or minor differences
                          }

                          function ActualOpenglCall(arg 1, arg2, arg3){//Symbol available in any OS
                          //Windows only Win32 API/WDDM and Linux specific
                          XyzGraphicOperationLowLevel(arg 1, arg2, arg3, Ver43, isGLX);
                          //opengl specific code or minor differences
                          }

                          so both DirectX and OpenGL use XyzGraphicOperationLowLevel[shared code] and that function is on any driver regardless the OS but ActualDirectXCall[specialized Code] is only available with a windows OS driver but ActualOpenglCall[specialized Code] is available everywhere, the problem as you see is that ActualDirectXCall uses Windows specific API and need to be rewritten to support Posix API too and make the symbol available in Linux which may require many changes at kernel level API since linux and NT handle things very differently

                          i hope is more clear now


                          How that answers to me? Is it possible for any compiler in the earth to be OS-specific? You say i can't implement just only the HLSL compiler to Wine?

                          Comment


                          • Originally posted by bridgman View Post
                            Can you point me to that post please ? In every post I could find I said that the D3D and GL drivers were separate. They share the back end shader compiler (AMDIL to HW instructions) but the driver and front-end compilers (GLSL to AMDIL, HLSL to AMDIL) are different and independent.

                            http://phoronix.com/forums/showthrea...730#post311730

                            http://phoronix.com/forums/showthrea...272#post311272

                            http://phoronix.com/forums/showthrea...765#post311765


                            So you say that the Windows driver has actually two drivers? One for D3D and one for OGL? Every FX is written two times?

                            As for the two front-ends i said that are different and you not provide both with the Linux driver.

                            Comment


                            • Yes, two drivers. Not sure of current names but something like atidxx32.dll and atioglxx.dll...

                              What do you mean by FX ?
                              Last edited by bridgman; 04-03-2013, 07:58 PM.

                              Comment


                              • Originally posted by artivision View Post
                                How that answers to me? Is it possible for any compiler in the earth to be OS-specific? You say i can't implement just only the HLSL compiler to Wine?
                                1.)"s it possible for any compiler in the earth to be OS-specific?" yes, if both all oses run on the same architecture any compiler do the job since the IR and the final ASM/Nmemonic is for the same hardware but for example linux/solaris run on sparc but windows don't, so you dont have the OS support or way to make a compiler that support sparc since the final ASM/Nemonic are specific for sparc and wont run on anything beside linux/solaris, hence making the compiler use specific kernel routines on those OSes[Posix] too, hence is not possible to compile this compiler on windows or run the result compiled binary on windows, hence OS dependant.

                                2.) You say i can't implement just only the HLSL compiler to Wine?

                                a.) you can but the result should be able to be interpreted by OpenGL since you don't have an DirectX driver and a compiler is lower than the wine DirectX layer and wine translate to opengl anyway
                                b.) you can use specific IR like AMDIR/nVIR/TGSI/Etc. but then you have to manually handle how the context will interpret and link the shader to a GL object inside the framebuffer since again you don't have a DirectX driver
                                c.) make a DirectX driver yourself, patch wine and add the compiler to the driver
                                Last edited by jrch2k8; 04-03-2013, 08:03 PM.

                                Comment

                                Working...
                                X