Bug 40931 - r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode.
Summary: r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode.
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-16 03:17 UTC by Andy Furniss
Modified: 2012-11-02 14:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Sugested workaround (2.62 KB, patch)
2011-09-16 09:45 UTC, Christian König
Details | Splinter Review

Description Andy Furniss 2011-09-16 03:17:25 UTC
Using rv790 grey is rendered with VDPAU/XVMC decode since

commit f2bae9456f141f8c1104ef2a0aab31f6190ae5f0
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Sep 15 12:41:00 2011 +0100

    r600g: interpret integer texture types as ints.
    
    For signed/unsigned with no normalisation or srgb, assume its an INT
    type texture.
Comment 1 Dave Airlie 2011-09-16 06:21:44 UTC
can you try with current master?
Comment 2 Andy Furniss 2011-09-16 07:42:32 UTC
(In reply to comment #1)
> can you try with current master?

It's still not rendering.
Comment 3 Christian König 2011-09-16 09:45:32 UTC
Created attachment 51268 [details] [review]
Sugested workaround
Comment 4 Christian König 2011-09-16 09:52:30 UTC
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.
Comment 5 Marek Olšák 2011-09-16 11:16:13 UTC
(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.
Comment 6 Andy Furniss 2011-09-16 11:27:05 UTC
(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.
Comment 7 Kai 2011-09-24 05:53:09 UTC
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.
Comment 8 Andy Furniss 2011-09-26 03:18:16 UTC
(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.
Comment 9 Andreas Boll 2012-11-02 14:31:54 UTC
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.