Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
Hi Bryan, Am Donnerstag, den 05.05.2011, 23:14 -0500 schrieb Bryan Cain: I found out the other day that nv50 doesn't support disabled GL rasterization rules, and doesn't plan to. Could iDCT be changed to work with GL rasterization rules enabled, or is there a reason that it can't or shouldn't use them? I just changed to zscan and idct code to work even with GL rasterization rules enabled, so at least this should now work on your NV50 hardware. Please fetch the current code and try again, there is really a good chance that it now works as intended. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
Am Donnerstag, den 05.05.2011, 23:14 -0500 schrieb Bryan Cain: I found out the other day that nv50 doesn't support disabled GL rasterization rules, and doesn't plan to. Could iDCT be changed to work with GL rasterization rules enabled, or is there a reason that it can't or shouldn't use them? Yes thats indeed easy to fix, I have developed the iDCT code with enabled GL rasterisation rules in the first place and then disabled them because it mades a couple of things easyer to implement. I just put it on the todo list, I will leave you a note when this is fixed so you can retest it. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
On 05/06/2011 03:59 AM, Christoph Bumiller wrote: On 06.05.2011 06:59, Bryan Cain wrote: I found out the other day that nv50 doesn't support disabled GL rasterization rules, and doesn't plan to. Could iDCT be changed to work with GL rasterization rules enabled, or is there a reason that it can't or shouldn't use them? NV50 as in the hardware here. At least as far as we could find. I suppose adjusting the viewport translation by -0.5 might help, but I'd rather not. And if you want me to change the top-left rule into something else, you're completely out of luck. I don't. That's why I'm asking Christian to change the iDCT instead of asking you to change the driver. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
2011/4/27 Christian König deathsim...@vodafone.de Regarding the not working idct on nvidia hardware I would guess that we use something that the driver currently doesn't supports, like multiple render targets, disabled opengl rasterisation rules, unsupported intermediate buffer format or something else. Hi Christian, I found out the other day that nv50 doesn't support disabled GL rasterization rules, and doesn't plan to. Could iDCT be changed to work with GL rasterization rules enabled, or is there a reason that it can't or shouldn't use them? Regards, Bryan. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
2011/4/26 Christian König deathsim...@vodafone.de Am Dienstag, den 26.04.2011, 17:53 + schrieb youne...@gmail.com: Hi Christian, Thanks for spending so much time on continuing this. I haven't really touched it since you started, but someone else had some patches for basic NV50 support. I don't recall who but I hope they can comment and are interested in getting their changes merged. Also, your implementation of interlaced MC breaks older chips that lack shader control flow if I'm not mistaken, but that can probably be fixed without much trouble.. Finally, someone else (Jimmy Rentz) had some patches that implemented hardware decoding on NV40 chips, but they were never merged into nouveau DRM and the pipe-video patches won't apply anymore anyhow. Those changes required a bit of work in pipe-video to support planar surfaces, but it worked quite well with the old vl_compositor. Recently Ben Skeggs added HW decoder bits to nouveau's DRM so if anyone is motivated enough to rework the userspace side it will require proper planar surface support in pipe-video. (This is just an FYI for anyone who is paying attention to pipe-video.) Cheers. If I remember correctly Bryan Cain was working on getting this to work again on NV50, he had MC working, but was struggling with the iDCT code. I also stumbled over the issue of planar texture resources, and solved it by implementing an abstraction class that uses up to three separate textures to emulate the behaviour of an YV12 or NV12 texture. If a hardware driver has native support for planar buffers it should be easy to override the creation function and use a native buffer instead. So things like: native idct - shader base mc or shader based idct - native mc should now be easily possible. But there is still allot of work todo. Regards, Christian. Yes, I got MC working on nv50 but couldn't get the iDCT to work properly. I still need to send in the patches for what I did accomplish. Should I send them to the mesa-dev mailing list and just label them as being for the pipe-video branch? Regards, Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
Hi Bryan, Am Mittwoch, den 27.04.2011, 09:31 -0500 schrieb Bryan Cain: Yes, I got MC working on nv50 but couldn't get the iDCT to work properly. I still need to send in the patches for what I did accomplish. Should I send them to the mesa-dev mailing list and just label them as being for the pipe-video branch? Looks like I missed your last mail, mhm I would guess that depends on the patches you made. Did you change the driver, state tracker or auxiliary stuff? Just rebase them to the current branch and then send them to me and cc the list so if there are changes to the driver the other nvidia developer can also get a look on them. Regarding the not working idct on nvidia hardware I would guess that we use something that the driver currently doesn't supports, like multiple render targets, disabled opengl rasterisation rules, unsupported intermediate buffer format or something else. Try again with the latest branch, since I have added some checks for unsupported stuff that will now report an error, which was silently failing before. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
[Sending this message to the list since I accidentally sent it to the list earlier from a non-subscribed address.] 2011/4/26 Christian König deathsim...@vodafone.de Am Dienstag, den 26.04.2011, 17:53 + schrieb youne...@gmail.com: Hi Christian, Thanks for spending so much time on continuing this. I haven't really touched it since you started, but someone else had some patches for basic NV50 support. I don't recall who but I hope they can comment and are interested in getting their changes merged. Also, your implementation of interlaced MC breaks older chips that lack shader control flow if I'm not mistaken, but that can probably be fixed without much trouble.. Finally, someone else (Jimmy Rentz) had some patches that implemented hardware decoding on NV40 chips, but they were never merged into nouveau DRM and the pipe-video patches won't apply anymore anyhow. Those changes required a bit of work in pipe-video to support planar surfaces, but it worked quite well with the old vl_compositor. Recently Ben Skeggs added HW decoder bits to nouveau's DRM so if anyone is motivated enough to rework the userspace side it will require proper planar surface support in pipe-video. (This is just an FYI for anyone who is paying attention to pipe-video.) Cheers. If I remember correctly Bryan Cain was working on getting this to work again on NV50, he had MC working, but was struggling with the iDCT code. I also stumbled over the issue of planar texture resources, and solved it by implementing an abstraction class that uses up to three separate textures to emulate the behaviour of an YV12 or NV12 texture. If a hardware driver has native support for planar buffers it should be easy to override the creation function and use a native buffer instead. So things like: native idct - shader base mc or shader based idct - native mc should now be easily possible. But there is still allot of work todo. Regards, Christian. Yes, I got MC working on nv50 but couldn't get the iDCT to work properly. I still need to send in the patches for what I did accomplish. Should I send them to the mesa-dev mailing list and just label them as being for the pipe-video branch? Regards, Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
On , Christian König deathsim...@vodafone.de wrote: Hi Andy and everybody on the list, sorry for the late reply, but i've been on vacation the last couple of days. Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss: In addition to the quit crash I notice that resizing will also crash. Should be fixed by now. I implemented most of the missing base functionality in vdpau state tracker, so video displaying should now work fine. When testing this HD vid - http://www.w6rz.net/newmobcal1920.ts It played and looked OK for about 5 seconds, but then stopped and I got lots of - radeon_bo_fixed_map failed to map bo EE radeon_bo.c:120 radeon_bo - failed to map bo I couldn't reproduce the error, but it sounds like a out of (video) memory problem to me. Please try again and see if it still crashes. Additional to the work on the vdpau state tracker, I've worked on the xvmc and general decoding stuff a bit more: * Added attributes for brightness, contrast, saturation, hue and colourspace * Got xines xxmc output plugin working with the xvmc implementation * Fixed the bug in the mc code that caused most of the artefacts in the pendulum video * Reorganized and cleaned up the xvmcdriver interface so it's using allot less cpu power. * Implemented basic support for a zscan and quantification stage To sum it up: Video output of a 1920x1080 video now uses something around ~20% CPU time on my old test system, compared to ~50% with Xv, including all the nice features like overlay menu rendering for example (ok only working with mplayer right now, not xine). So is there something still missing for the xvmc state tracker, or can I continue with implementing the vdpau state tracker? Regards, Christian. Hi Christian, Thanks for spending so much time on continuing this. I haven't really touched it since you started, but someone else had some patches for basic NV50 support. I don't recall who but I hope they can comment and are interested in getting their changes merged. Also, your implementation of interlaced MC breaks older chips that lack shader control flow if I'm not mistaken, but that can probably be fixed without much trouble. Finally, someone else (Jimmy Rentz) had some patches that implemented hardware decoding on NV40 chips, but they were never merged into nouveau DRM and the pipe-video patches won't apply anymore anyhow. Those changes required a bit of work in pipe-video to support planar surfaces, but it worked quite well with the old vl_compositor. Recently Ben Skeggs added HW decoder bits to nouveau's DRM so if anyone is motivated enough to rework the userspace side it will require proper planar surface support in pipe-video. (This is just an FYI for anyone who is paying attention to pipe-video.) Cheers. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
Am Dienstag, den 26.04.2011, 17:53 + schrieb youne...@gmail.com: Hi Christian, Thanks for spending so much time on continuing this. I haven't really touched it since you started, but someone else had some patches for basic NV50 support. I don't recall who but I hope they can comment and are interested in getting their changes merged. Also, your implementation of interlaced MC breaks older chips that lack shader control flow if I'm not mistaken, but that can probably be fixed without much trouble.. Finally, someone else (Jimmy Rentz) had some patches that implemented hardware decoding on NV40 chips, but they were never merged into nouveau DRM and the pipe-video patches won't apply anymore anyhow. Those changes required a bit of work in pipe-video to support planar surfaces, but it worked quite well with the old vl_compositor. Recently Ben Skeggs added HW decoder bits to nouveau's DRM so if anyone is motivated enough to rework the userspace side it will require proper planar surface support in pipe-video. (This is just an FYI for anyone who is paying attention to pipe-video.) Cheers. If I remember correctly Bryan Cain was working on getting this to work again on NV50, he had MC working, but was struggling with the iDCT code. I also stumbled over the issue of planar texture resources, and solved it by implementing an abstraction class that uses up to three separate textures to emulate the behaviour of an YV12 or NV12 texture. If a hardware driver has native support for planar buffers it should be easy to override the creation function and use a native buffer instead. So things like: native idct - shader base mc or shader based idct - native mc should now be easily possible. But there is still allot of work todo. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
