AMD Releases Open-Source UVD Video Support

[artivision]

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.

[bridgman]

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/showthread.php?77553-Gaming-On-Wine-The-Good-amp-Bad-Graphics-Drivers&p=311730#post311730

http://phoronix.com/forums/showthread.php?77447-John-Carmack-Pushes-Wine-For-Linux-Gaming&p=311272#post311272

http://phoronix.com/forums/showthread.php?77553-Gaming-On-Wine-The-Good-amp-Bad-Graphics-Drivers&p=311765#post311765

[jrch2k8]

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

[liam]

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/mesa/tree/src/gallium/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...

[agd5f]

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/mesa/tree/src/gallium/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.

[liam]

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

[artivision]

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?

[artivision]

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/showthread.php?77553-Gaming-On-Wine-The-Good-amp-Bad-Graphics-Drivers&p=311730#post311730

http://phoronix.com/forums/showthread.php?77447-John-Carmack-Pushes-Wine-For-Linux-Gaming&p=311272#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.

[bridgman]

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

What do you mean by FX ?

[jrch2k8]

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