+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder (/showthread.php?tid=40362)
- CapnBry - 2009-01-07 18:34
malloc Wrote:Could just have GL render to texture of appropriate size and then read the texture to local memory. Of course then we just write it back to the card for VDPAU to use.Yeah but last I checked that was impossible at 1080p60. Doing a quick test on my laptop I top out at 25fps reading back from an XBMC screen rendered-to-texture at 720p resolution. 2 GHz Core2Duo CPU was pegged.
I then wrote a PBO pack implementation, which would exhibit a 1 frame lag from what we'd actually like to render but I don't think that would be a problem as we're not writing a first person shooter here. After spending the time writing it, then trying to figure out why it kept crashing, turns out my laptop doesn't support PBOs. /facepalm
EDIT: God I hate bumping this thread. (cringe)
- mythmaster - 2009-01-07 20:10
*IF THERE IS INTEREST*, I'm willing to start a separate project for developers to work specifically on VDPAU support. IMO, it would be better to do it this way since it requires such a major overhaul. I'm not familiar enough with XBMC's code or skilled enough to actually contribute any changes, but I can at least do this.
Even if you elect not to do this, I want to express my gratitude for the awesome work you've all done providing us with this kick-ass software.
- topfs2 - 2009-01-07 20:47
mythmaster Wrote:*IF THERE IS INTEREST*, I'm willing to start a separate project for developers to work specifically on VDPAU support. IMO, it would be better to do it this way since it requires such a major overhaul. I'm not familiar enough with XBMC's code or skilled enough to actually contribute any changes, but I can at least do this.
Even if you elect not to do this, I want to express my gratitude for the awesome work you've all done providing us with this kick-ass software.
No need for a different project, just branching it will be more than sufficient. (This will make it a completely new copy of the sourcebase which any developer could do whatever on, we already have alot of additions in branches, like HD Flagging, Kareoke, 7z support etc.. most of them contain alot of changes)
We dont need any more XBMC Clones
Cheers,
Tobias
The other way (Open CL) - dmidi - 2009-01-07 21:15
malloc Wrote:Could just have GL render to texture of appropriate size and then read the texture to local memory. Of course then we just write it back to the card for VDPAU to use.
I'm not saying VDPAU should be dropped like a hot overloaded software decoding CPU trying to also do memory swaps....but there is another way that involve less invasive surgery on XBMC's OpenGL approach.
• OpenCL can efficiently share resources with OpenGL
- Textures, Buffer Objects and Renderbuffers
- Data is shared, not copied
- OpenCL objects are created from OpenGL objects
- clCreateFromGLBuffer(), clCreateFromGLTexture2D(), clCreateFromGLRenderbuffer()
OK forum moderators...you can say this is irrelevant and move this post (but why the insistence on pursuing a beta Nvidia technology that's so kludgey for XBMC?)
No more talk about OpenCL in this thread please. Stick on topic to VDPAU API. - Gamester17 - 2009-01-07 22:10
dmidi Wrote:OK forum moderators...you can say this is irrelevant and move this postYes OpenCL is irrelevant for this specific thread, please stop thread hi-jacking in order to try to lobby OpenCL.
Friendly warning this time only...
- mythmaster - 2009-01-07 22:17
Topfs2 Wrote:No need for a different project, just branching it will be more than sufficient.
Groovy!
(I wasn't advocating a clone, btw)
Lotsa work...little gain if system memory/CPU extensively involved - dmidi - 2009-01-08 00:01
Gamester17 Wrote:Yes OpenCL is irrelevant for this specific thread, please stop thread hi-jacking in order to try to lobby OpenCL.
Friendly warning this time only...
Just pointing out that memory swapping is avoided by an alternative GPU decode method (see I didn't even name it!). If system-gpu memory swaps are the only way to make VDPAU work on XBMC, then I don't think it will be beneficial.
GPU acceleration takes advantage of the massive on board memory bandwidth and parallel processing of the GPU architecture. Having the CPU so intensively involved will negate any theoretical efficiency/fps increases...the GPU will be in perpetual 'hurry up and wait-wait-wait' mode.
The mismatch imposed by intensive CPU/system RAM involvement will be even more apparent on precisely the systems that would most benefit from GPU acceleration: namely systems that have slower processors but relatively powerful GPU's. All the 2 year old systems with Nvidia/ATI h.264 enabled GPU's but slower dual cores (to say nothing of netbooks) will still be hobbled in 1080p playback. So all that work for little gain.
- Silverbolt - 2009-01-08 03:48
dmidi Wrote:OK forum moderators...you can say this is irrelevant and move this post (but why the insistence on pursuing a beta Nvidia technology that's so kludgey for XBMC?)
There's one huge reason why any developer would consider an implementation of VDPAU: it uses the decoding logic that is already built into the video cards. To take advantage of VDPAU or DXVA, the developers just have to pass the video bitstream to the video card for decoding. Finding a way to get VDPAU working efficiently in XBMC is probably much easier than writing an AVC decoder from scratch using a brand new programming language. Besides, if the XBMC developers wanted to write their own AVC video decoder, I think the GSOC project that uses OpenGL shaders would be an easier start point, since a lot of the work is already done.
I don't doubt that OpenCL would be a clean solution for GPU decode acceleration, but the other options seem to be easier to implement.
- althekiller - 2009-01-08 04:11
Someone didn't bother reading the thread...
- malloc - 2009-01-08 04:21
At 19 pages, even I wouldn't read the thread.