[vlc-devel] GSoC 2018 Idea `libplacebo Improvement'
Zhao Zhili
quinkblack at foxmail.com
Wed Mar 21 09:31:38 CET 2018
Hi,
On 2018年03月21日 15:54, Thomas Guillem wrote:
> On Wed, Mar 21, 2018, at 08:33, Steve Lhomme wrote:
>> I used to do that with D3D11. It was fine with an integrated (Intel)
>> GPU. But with discrete GPU the SW decoders were really slow. Having to
>> use memory via the PCI bus. To counter that I pretend to do direct
>> rendering and provide CPU memory and during prepare() I copy back to
>> the GPU. It's much faster for discrete GPUs and doesn't impact much
>> the integrated ones.
> Steve,
> With OpenGL 4.x, mapped buffer performances are really good with the
> discrete GPU I tested (GeForce GTX 660).For AMD GPUs, I had to map the buffer with the following option:
> GL_CLIENT_STORAGE_BIT in order to indicate that we prefer the buffer to
> be on the CPU side. Cf.
> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferStorage.xhtml
> Niklas,
> Don't forget that we also need feature parity with the OpenGL vout of
> VLC. This means: - Interop with VAAPI surfaces. VLC use the
> "EGL_EXT_image_dma_buf_import" extension. I guess we can do the same
> with Vulkan ? Mapping some DMA buffers to a texture ? - Bonus: Interop with cuda ? (It's not done yet on the GL side of VLC) - Give VLC a way to specify its own Vertex Shaders (for 360°,
> VR/3D stuff) .- And for Metal/MoltenVK: Interop with IOSurface/CVPixelBuffer.
Can we put these informations on wiki for tracking? It's really useful.
>
>> _________________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list