Kodi Community Forum
VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder (/showthread.php?tid=40362)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28


- CapnBry - 2009-01-07

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

*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. Cool


- topfs2 - 2009-01-07

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. Cool

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 Wink

Cheers,
Tobias


The other way (Open CL) - dmidi - 2009-01-07

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

dmidi Wrote:OK forum moderators...you can say this is irrelevant and move this post
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...


- mythmaster - 2009-01-07

Topfs2 Wrote:No need for a different project, just branching it will be more than sufficient.

Groovy! Smile

(I wasn't advocating a clone, btw)


Lotsa work...little gain if system memory/CPU extensively involved - dmidi - 2009-01-08

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

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

Someone didn't bother reading the thread...


- malloc - 2009-01-08

At 19 pages, even I wouldn't read the thread.


- CapnBry - 2009-01-08

CapnBry Wrote: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
I ran my alternating pixel buffer object implementation on an ATI 4850 last night, which does support PBOs. Even slower than regular glReadPixels.

To make sure it wasn't me being a retard, I grabbed a PBO unpack demo and it gets 450fps using glReadPixels, and 60fps with PBO reads. (The texture is very small in this demo)

So it would appear that rendering the UI to texture and reading it back to give to VDPAU is unfeasible at HD resolutions.


- mythmaster - 2009-01-08

CapnBry Wrote:I ran my alternating pixel buffer object implementation on an ATI 4850 last night, which does support PBOs. Even slower than regular glReadPixels.

To make sure it wasn't me being a retard, I grabbed a PBO unpack demo and it gets 450fps using glReadPixels, and 60fps with PBO reads. (The texture is very small in this demo)

So it would appear that rendering the UI to texture and reading it back to give to VDPAU is unfeasible at HD resolutions.

I don't know what method mythtv uses for its OSD that pops up with transparency and smoothly fades out on top of live hdtv, but it doesn't noticeably hit my cpu. The XBMC UI is admittedly more complex, but having a look at mythtv's code would be a good place to start because that was previously done with opengl.


- CapnBry - 2009-01-08

It just does software blending using QImages composited together IIRC.


Yes both MythTV and Xine supports OSD (On Screen Display) on top of VDPAU... - Gamester17 - 2009-01-09

mythmaster Wrote:I don't know what method mythtv uses for its OSD that pops up with transparency and smoothly fades out on top of live hdtv, but it doesn't noticeably hit my cpu. The XBMC UI is admittedly more complex, but having a look at mythtv's code would be a good place to start because that was previously done with opengl.
MythTV, Xine, and MPlayer all uses X11 renderers for VDPAU, not OpenGL, and if I'm not mistaken VDPAU API was designed for X11 (at least NVIDIA's patches for MPlayer and FFmpeg were)?

Might not be a bad idea though to look at both MythTV and Xine's VDPAU implementations?
http://mythtv.org/
http://xinehq.de/

Huh


- CapnBry - 2009-01-09

Gamester17 Wrote:Might not be a bad idea though to look at both MythTV and Xine's VDPAU implementations?
(Regarding MythTV) I did that the day the patches showed up on mythtv-dev Smile It is actually built inside their XVideo video output renderer. VDPAU and XV are very similar in setting up their presentation regions so it does make sense to do that. A quick check again shows that they allocate an OSD image the same size as the screen and composite UI elements together onto it, then pass the final image to VDPAU. So basically a software renderer. They also only have to deal with the OSD only being an OSD, which is pretty simplistic compared to the XBMC skinning engine (which would have to be ported in its entirety).

Maybe an option would be to do the render-to-texture-and-read-back for XBMC while playing video but run it at a reduced frame rate, like the OpenGL rendered part only updates 5 times a second? It would look like shit but it would work.

I still think the VDPAU->Pixmap and Pixmap->Texture method is the best option. I haven't had a chance to try it yet though, the hdflagging branch is where I spend any spare time I've got.