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.
(Just to remind AMD that we sitll want accelerated decoding :-)
mmmm... my view here is that isnt going to happen any time soon, expecially since stream techonology is missing from fglrx as far as i know and opencl is very further away in the future too.
beside fglrx code seems to be a trully mess and is very far away from windows equivalent + unstable as hell(at least in rv7xx chips). so adding this new stuff could break it even more(not being ironic it can be even worse than now even if is hard to imagine).
if your budget allow it do like me buy an nvidia gts250 that will fit fine for modest game and clear h264 play with vdpau until OSS drivers get full mesa support and gallium/openCL become usable cuz in fglrx is not going to happen and even if someday in fglrx 20.20 happens i really doubt would be any usable until fglrx 32.14 in 2034. but by then prolly my 128 cores 40 ghz cpu can handle BD just fine lol.
beside the homourus comment up, the truth here seems to be than first AMD dont care too much about fglrx cuz market issues and the code they got from ATI was a trully hellish completly undebugged code, plus AMD is producing new technologies like crazy in the gPU side (most productive part of AMD now) so it will take a long time to get a stable functional code because they seems to be forced to add code on the fly to support at least basically these tech beside the driver is stable or not. so more chaos to a chaotic code lol. so those of us that say ohh i love that 4800 card and commit the sin of use linux, our only hope is the OSS driver (which is going nice btw) cuz devs seems to put more thinking and optimization in the code, i guess is cuz of the lack of pressure of crazy enterprise politics and more access to OS info from already +AAAAA drivers like OSS intel.
so wait for OSS driver/gallium/opencl and later wait for xine/ffmpeg/VA-API opencl video accelaration infrastucture (maybe this come faster cuz nvidia have already a very nice openCL capable driver, so we dont have to wait for gallium or AMd at the very begining)
mmmm... my view here is that isnt going to happen any time soon, expecially since stream techonology is missing from fglrx as far as i know and opencl is very further away in the future too.
beside fglrx code seems to be a trully mess and is very far away from windows equivalent + unstable as hell(at least in rv7xx chips). so adding this new stuff could break it even more(not being ironic it can be even worse than now even if is hard to imagine).
The stuff is already there, all AMD has to do is open up their API.
The stuff is already there, all AMD has to do is open up their API.
well you think the code is already there cuz you see a library there, but there is a reason cuz is not operational dont you think? as far as im concerned that could be a loot of porn images in base64 put in a so file just to show something.
Did anybody really test vaapi? It is possible to test with GMA 500, G45/Q45 (there only Mpeg2) and via vdpau-video wrapper with vdpau capable cards. If you use debian or ubuntu just run this script:
which updates the mplayer to current svn, that works without problems currently. For the gl output vsync should be enabled for opengl. The script compiles the 965 driver which i tested worked for karmic at least. To test with nvidia all distros should work. I think testing vaapi is a good idea to know what is different to vdpau implementations (mplayer can do both with nvidia then).
Comment