Kodi Community Forum
XBMC for Linux VDPAU - NVIDIA GPU video decoding support (now in the mainline SVN) - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: XBMC for Linux VDPAU - NVIDIA GPU video decoding support (now in the mainline SVN) (/showthread.php?tid=45525)



- mythmaster - 2009-03-23

uomiarz Wrote:I just compiled 18839.
Did reallyclean and make install.

I go to render method, set it up for VDPAU and try to play something but render methid always defaults back to "Software"

What am I missing?
thx

ps. i had vdpau working before merge

I can reproduce, but leaving it on "Auto detect" uses vdpau. (r18835)


- uomiarz - 2009-03-23

mythmaster Wrote:I can reproduce, but leaving it on "Auto detect" uses vdpau. (r18835)

tried that before but no luck, tons of dropped frames and CPU at 100% tells me vdpau is not being used ( i guess it also gives the info when it uses it)


- tslayer - 2009-03-23

You need to provide more details. An xbmc.log would surely help.


- mythmaster - 2009-03-23

uomiarz Wrote:tried that before but no luck, tons of dropped frames and CPU at 100% tells me vdpau is not being used ( i guess it also gives the info when it uses it)

Yeah, pressing "o" during playback (artbeats demo) says (in part) "dc: ff-264_vdpau" while using "Auto select", but if I use "VDPAU", the "_vdpau" part will be gone, and when I go back to settings menu, "Software" will be selected. I have a quad-core & haven't tested CPU in such case.


- tslayer - 2009-03-23

Please stick to Auto for now.


- mythmaster - 2009-03-23

@uomiarz:

You might want to "make uninstall" and try a fresh linuxport checkout in a new dir like I did:
Code:
svn co https://xbmc.svn.sourceforge.net/svnroot/xbmc/branches/linuxport xbmc



- Haggy - 2009-03-23

@devs: Does the recent merge from xbmc-vdpau and thus requiring vdpau libs mean that non-nvidia/recent driver users cannot compile anymore? if i read back 2 pages there's someone who has a configure error saying -lvdpau fails.


- jyavenard - 2009-03-23

xnappo Wrote:You need 185.13 for more recent versions.

xnappo

185.13 has no change to 180.41 yet.

It's a branch nvidia created just to prepare for the next driver version.

I don't see how there could be any requirements from a development perspective for 185.xx that wouldn't work with 180.xx ...


- Haggy - 2009-03-23

OK, thanks to clear that up, so i suppose 185.13 is not needed anymore as a dependency. What about xbmc-vdpau branch? Is it abandoned now that it got merged to linuxport last night?


- jyavenard - 2009-03-23

Haggy Wrote:Sure it was in the log:
http://trac.xbmc.org/changeset/18605

and yes: you need 185.13 because of that change i think - but motd2k is more into the drivers features. also, 180.41 is another stable release, while 185.13 is called beta from nvidia itself.

I can't see anything here that could require 185.xx ...

I may be wrong here due to what is stated in the log. Why else would they have written that ?

Anyhow, I only got to that thread as I was looking at testing xbmc .. Haven't looked in the code in more details, and only using what nvidia engineers have stated in their forums ...


- motd2k - 2009-03-23

jyavenard Wrote:185.13 has no change to 180.41 yet.

It's a branch nvidia created just to prepare for the next driver version.

I don't see how there could be any requirements from a development perspective for 185.xx that wouldn't work with 180.xx ...

Hi - glad to see you over here!

185.x currently contains a fix which we require relating to spec compliance of glXBindTexImageEXT. In the 180 series (including .41) the driver consumes 100% processor time when you bind/release the pixmap from the GL texture everytime you use the texture, which according to spec is the correct way. If you, however, bind the texture once (when VDPAU is initialized), and release once (when VDPAU is destroyed!) the 180 range works perfectly. I believe Compiz call this 'strict-binding'.

Being cross-platform, and with the possibility that Intel were going to add VDPAU capabilities, it's best for us to stick to the letter to the OpenGL spec, rather than relying on a particular vendor's peculiarities - hence the need for 185.13... There certainly are differences between 180 and 185, hopefully this fix will get backported into 180 though.


motd


NB http://people.freedesktop.org/~davidr/GLX_EXT_texture_from_pixmap.txt See 'Issues' #5.


- motd2k - 2009-03-23

Haggy Wrote:OK, thanks to clear that up, so i suppose 185.13 is not needed anymore as a dependency. What about xbmc-vdpau branch? Is it abandoned now that it got merged to linuxport last night?

xbmc-vdpau is going to continue with my personal fixes for things that linuxport doesnt yet support. There's several important thing that i'll be putting back in there (those who followed the branch probably know that - rightfully - i've not had much creative freedom over it whilst the merge was being prepared!)... so 8200 fullscreen testing, and subtitles/overlay support on their own GL texture would be big candidates right now.


- Haggy - 2009-03-23

ok, so i'll continue providing the xbmc-vdpau branch as a PKGBUILD. Thought i'd close it down after yesterday's merge. any updates on arch, motd2k?


- motd2k - 2009-03-23

Plan to offer up a sacrificial 2-hours today... if it continues to bite back it'll be back to Ubuntu for the moment!!!


- Haggy - 2009-03-23

...i stay @irc :-)