AMD Releases Open-Source UVD Video Support

[jrch2k8]

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.

well ofc binary drivers handle both directx and opengl and their respective shading languages but that is like say interpret the C bytecode with glibc from MSVC one cuz the CPU accept both, meaning their DX path are enterely WinAPI with Microsoft driver model so it will imply a massive rewrite to make usable on linux/etc. Unlike Opengl which is by default crossplataform so they take the compatibility path from scratch

[agd5f]

Serious Sam works on r600g same as on Catalyst at least for my humble 5730M. (Bad in both cases :P)

I'm not sure if it's a bug in the app or in mesa, but disabling the GL_ARB_get_program_binary extension seems to fix Serious Sam.

MESA_EXTENSION_OVERRIDE="-GL_ARB_get_program_binary"

[artivision]

1.) btw you most likely can't do that without a kernel module since linux don't allow direct hardware access like windows
2.) i really doubt someone actually implement it since will require a massive amount of work for not much gain at the end and the security risk of doing so are big enough
3.) this will probably will require additional driver support an a protocol to do so which will prolly take long time assuming nVidia/AMD even care to do so [i bet you gallium just won't, at all]

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?

[GreatEmerald]

[maybe unreal4 but not sure yet]

Unreal Engine 4.

3.) nope, only r600g have an experimental LLVM backend and no commercial driver has it either[LLVM i mean] and either way is not that simple cuz Wine could today implement a direct TGSI pass and forget the conversion but then only Gallium drivers would work or use direct GPU ASM so any GPU would work but prolly at the cost of new 5 million LoC and beyond all that you still need to parse and run basic security/stability checks[this is done by windows too at driver level] and even so Windows drivers have a bazillion of hacks to improve performance in selected games due to ultra crappy routines/spec violations/by hand slow ASM that game studios never fixes[especially unreal].

Unreal Engine. As for the actual Unreal, it doesn't use the GPU for much at all. It was written for use with a software renderer first and foremost, since at the time there were a lot of different GPU manufacturers and they couldn't rely on any particular functionality being provided. And their main focus aside from software rendering was actually the 3dfx Glide (for Voodoo cards). Plus, it's no longer maintained by the company, and its source is now maintained by the fanbase instead. I could ask how much ASM is used in it if you like, though

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.

Ether may be basic organic chemistry, but hey, that's not very relevant in this particular topic

[jrch2k8]

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?

is not the GPU won't accept is more like the kernel won't let you get to it unless the kernel have a way to handle it itself, that is why DRM and KMS exist

[jrch2k8]

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

[artivision]

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???

[jrch2k8]

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

[oliver]

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

[stqn]

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.