If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Testing The Open-Source "RADV" Radeon Vulkan Driver vs. AMDGPU-PRO
irrelevant, intel does not use llvmlol, that compiler will generate code for intel gpus
Nir is an IR and in theory SPIR-V should in theory be portable to the mesa compiler that intel uses. Since AMD Gallium driver don't use NIR i had doubts which parts they used. but whatever B already answered that NIR->LLVM.
My point was on SPIR-V to NIR IR, since both intel and RADV use it, it should help having more eyes optimizing this stage then easying the job of their respective compilers and layers after it.
Btw. an article about the state of HEVC Main 10 decode would be interesting as vdpauinfo/vainfo show support for it with Polaris GPUs.
For what i've tested, hardware decoding of hevc in main10 in polaris works like a charm, in vaapi. For that i used ffmpeg-git + this homemade patch: http://ffmpeg.org/pipermail/ffmpeg-d...st/197623.html then use mpv with -hwdec=vaapi and opengl renderer.
But i've also noticed some problems when hardware decoding a simple mpeg2 from a dvd on a rx480. That i don't know where the problem is
(bad looking blocks, sometimes even flickering blocks)
Wow. This is impressive. Well done David & Bas!
Do you have plans to backport it to CI and SI?
Well if the GCN 1.0 AMDGPU support lands on 4.9, it should be mostly doable on all GCN able hardware except when you need hardware specific fixes that could take more time
it's not just legal review. somebody has to turn windows vuklan driver to opensourceable form. they have no resources for that, so do not expect they will magically find resources to maintain another driver
Right... we knew at the start that any IP/Legal review would fail dramatically (and it did)... the work involved rewriting big chunks of the driver, and the driver itself is already much larger because it shares code across multiple OSes and multiple APIs.
When trying Dota 2 with fullscreen mode at various resolutions, the screen basically appeared locked and wouldn't update past the loading screen. But when alt-tabbing out of the game, a few new frames of the game's demo would proceed to appear... Alt-tabbing again, a few more frames. Or if leaving the game minimized so it would be off-screen, the demo would complete but would get just a few frames per second.
I tried enabling/disabling the Steam overlay, switching between the AMDGPU and modesetting DDX drivers, switching from Compiz/Unity to Xfce with/without compositing, and other steps to try to figure out why the screen wouldn't update in the full-screen mode. But the easiest approach for now was just running Dota 2 in windowed mode. When in windowed mode, there were no issues.
Right... we knew at the start that any IP/Legal review would fail dramatically (and it did)... the work involved rewriting big chunks of the driver, and the driver itself is already much larger because it shares code across multiple OSes and multiple APIs.
Does this mean the release is just stalled but is still coming? or do you have no idea/not allowed to say?
Right... we knew at the start that any IP/Legal review would fail dramatically (and it did)... the work involved rewriting big chunks of the driver, and the driver itself is already much larger because it shares code across multiple OSes and multiple APIs.
Would it then just make more sense to support the RADV driver?
It seems to be off to a really good start.
Sigh, pesky legal BS...
Comment