Summary: | r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode. | ||
---|---|---|---|
Product: | Mesa | Reporter: | Andy Furniss <adf.lists> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | kai |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Sugested workaround |
Description
Andy Furniss
2011-09-16 03:17:25 UTC
can you try with current master? (In reply to comment #1) > can you try with current master? It's still not rendering. Created attachment 51268 [details] [review] Sugested workaround Hi Dave & Andy, I think we have a disagreement here about what SCALED types should be. As I understood it SCALED types should be represented as integers in memory, but when loaded into a shader converted to floats in the range 0..2^n (in opposite to normalized types), and that's how I used them in g3dvl. I also added code to r600g to support those types as textures and render target, but this code got removed before merge because I figured out why working with normalized textures/render targets didn't got the expected results. @Andy: The attached patch should fix your issue, but I will delay committing it until we have figured out how SCALED types should be really handled. (In reply to comment #4) > Hi Dave & Andy, > > I think we have a disagreement here about what SCALED types should be. > > As I understood it SCALED types should be represented as integers in memory, > but when loaded into a shader converted to floats in the range 0..2^n (in > opposite to normalized types), and that's how I used them in g3dvl. That's right if you are talking about USCALED. (In reply to comment #4) > @Andy: The attached patch should fix your issue, but I will delay committing it > until we have figured out how SCALED types should be really handled. OK, I can confirm it does fix it. Without attachment 51268 [details] [review] applied, I see the grey area described in comment #0 but when I run $ VDPAU_DRIVER=r600 mplayer -fs -aid 0x82 -sid 7 -vo vdpau -vc ffmpeg12vdpau dvd://1 with the workaround applied, I get: > mplayer: vl/vl_mpeg12_bitstream.c:980: vl_mpg12_bs_decode: Assertion `consumed <= num_bytes' failed. I'm using Mesa from master (d7cdbc3c), mplayer is at 1.0~rc4+svn20110809 (from debian-multimedia.org). PCI ID for the GPU 1002:9553. (In reply to comment #7) > Without attachment 51268 [details] [review] applied, I see the grey area described in comment #0 > but when I run > $ VDPAU_DRIVER=r600 mplayer -fs -aid 0x82 -sid 7 -vo vdpau -vc ffmpeg12vdpau > dvd://1 > with the workaround applied, I get: > > mplayer: vl/vl_mpeg12_bitstream.c:980: vl_mpg12_bs_decode: Assertion `consumed <= num_bytes' failed. Probably not related to the fix as such, but I also have problems with streams that just stop - or (only just tested) dvd://. For me dvd:// just hangs requiring a kill -9. It will work if I use -cache 20000. I also just noticed that using -vo vdpau subs/control overlay will be incorrectly positioned/sized after toggling to and back from fullscreen. Fixed with 86f97f7dc015092aa7fa1b0bdc4fe0a9f696d418 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.