This driver is already there.
Type: Posts; User: LiquidAcid; Keyword(s):
This driver is already there.
Check if you've set a offloadsink and if that doesn't help, file a bugreport.
This should of course read "GLX DRI2 offloading". I don't think the nine state tracker does any kind of offloading yet.
That does not make any sense. You either use DRI3, or you use DRI2. And DRI2 offloading works, you just have to have a DDX loaded for the secondary card.
It uses DRI2 (see d3dadapter.c). Someone would have to rewrite this using DRI3 and Present. I had a quick look at it, but I don't have any clue where to start. First step would probably to implement...
I say it again, read about DeviceTree. You can assume all day why this and that should be trivial to implement, but reality still looks different. Also from what I read, you haven't even touched any...
schmidtbag, you should then start reading about DeviceTree, and why it's a necessity for the ARM world. What works on x86 simply doesn't on ARM. You've got virtually no good way to discover hardware...
Wrong. The Mali kernelspace driver is open-source and provided by ARM itself. Also, when I speak about upstreaming code, I don't refer to Mali but:
- providing a DTS (like the ODROID-X has in...
Correct, there is no upstream support for the ODROID-X2,U2,U3 (Exynos4-based) or the XU (Exynos5-based). And Hardkernel doesn't seem to be interested in upstreaming any of their code.
This lxBDPlayer is just some bundled package consiting of DumpHD, mplayer and makemkv (makemkv for the actual AACS and BD+ decryption). It's all tied together with some Java code.
This ennvar doesn't do anything anymore.
You should ask Jerome that question. But from the first commit message (see the log):
So it looks like some compiler / compiler infrastructure.
I wonder how this interacts with this VITE thing Jerome Glisse has in his personal mesa repo:
IIRC it should also provide a better compiler...
Seconding this. vaapi support is the only missing feature now for me. Still using the mplayer-vaapi version from splitted-desktop, plus a mplayer2 binary and a regular (vanilla) mplayer binary.
I'll probably happen sometime after i915g is in a more or less stable state, which can still take a while.
Any yes, people interested in the development going on in mesa should just bookmark the...
Pretty sure this just the gamecode he did compile (like the one that is included in Valve's HL2 SDKs). The renderer code isn't available to the public anyway.
libtxc_dxtn wasn't written by Marek, he's just "maintaining" it currently. The original code was written by Roland Scheidegger, which is immediately obvious from the sourcecode.
Specify "next version".
Intel devs coded an entirely new GLSL compiler, that is certainly true. However this doesn't automatically give you support for every GLSL version out there.
I think the changes to GLSL and the support for integer texture formats is probably the largest work that remains.