[Mesa-dev] XvMC gets iDCT support (at least on R600)

[Alex Deucher]

2010/11/23 Christian König <deathsimple at vodafone.de>:
> Am Sonntag, den 21.11.2010, 11:28 -0500 schrieb Alex Deucher:
>> Make sure you are using the latest drm patches.  Dave and I fixed a
>> number of bugs in the CS checker in 2.6.37.  Also, make sure you have
>> the latest mesa bits.  I fixed the buffer alignment handling in r600g.
> Just merged my mesa branch with master yesterday, I will update the
> kernel as soon as I find time to do so.
>
> But i don't think that this is already fixed: If i add a new colour
> format to the r600_translate_colorswap function in r600_state_inlines.h,
> but forget to also add those to the r600_translate_colorformat function
> I get a nice opps because of a divide by zero in the drm code,
> completely crashing the graphics subsystem.

That should be fixed already.

>
> Trying to use a constant as a texture locations also results in an gpu
> hangup/reset. This should also be prevented in the cb checker (or does
> it checks only the "real" command buffer and not the shaders itself?).
>

It doesn't check the shaders, it just checks the command stream to
make sure the enabled buffers are valid and to translate the bo
handles to MC addresses.

> And when the drm code detects a hanging command buffer and resets the
> gpu, it would be nice to kill the process that issued this command
> buffer, because it make no sense that an userspace application keeps
> issuing the same invalid command buffer over and over again (after an
> reasonable amounts of retries of course).
>
>> Using tiled surfaces may help if you are doing a lot of texture
>> lookups.  There is support in r600g if you are using the latest drm
>> and mesa code.
> How far goes tilling on r600 hardware? Is it one, two or tree layer
> tilling? What i mean is this:
>
> Normal linear layout:
> A B C D E F G H I J K L M N O P
>
> One layer tilling:
> A B E F I J M N
> C D G H K L O P
>
> Two layer tilling:
> A B E F
> C D G H
> I J M N
> K L O P
>
> And so on, (if I understood the concept of tilling right).

There are two types of tiling you can enable, 1D, and 2D.  1D
basically divides up the buffer into 8x8 pixel micro tiles.  2D tiling
uses larger macro tiles made up of micro tiles, hence the 1D and 2D.
Tiling is meant to maximize cache locality and memory bandwidth.  1D
tiles map roughly to a cache line and you get better cache utilization
for a tile rather than a scanline as you have similar addresses in 2D
space closer together.  Macro tiles maximize bandwidth by optimally
distributing load across all memory channels.  For optimal
performance, tiling should always be enabled, but it requires a fair
amount of driver infrastructure which is just now coming online.
E.g., if you want to manipulate a tiled buffer with the CPU, you'd
need to either calculate the addresses yourself on a per-pixel basis,
or you need to use the 3D engine to blit to a linear buffer.

>
> For an iDCT of a 8x8 pixel block I would need tree layer tilling, so a
> 8x8 block of 64 elements are stored linear "near" to each other in
> memory. Would that work on the hardware?

It's transparent to the application, but it sounds like it would
probably help in this case.

>
> Another thing that would really help is if I could calculate 4 elements
> in one pixel shader run instead of just one, but for this to I would
> need R32G32B32A32 colour buffers, and I simply can't get them to work
> probably.
>
> I added the following lines to the r600_cb function in r600_state.c:
>        desc = util_format_description(rtex->resource.base.b.format);
>        if (desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB)
>                ntype = V_0280A0_NUMBER_SRGB;
>        else if (desc->layout == UTIL_FORMAT_LAYOUT_PLAIN) {
>                switch(desc->channel[0].type) {
>                case UTIL_FORMAT_TYPE_UNSIGNED:
>                        ntype = V_0280A0_NUMBER_UNORM;
>                        break;
>
>                case UTIL_FORMAT_TYPE_SIGNED:
>                        ntype = V_0280A0_NUMBER_SNORM;
>                        break;
>                }
>        }
> This seems to get R16_SNORM colour buffers working, but texture uploads
> and even a simple R32_FLOAT colour buffer won't work right. I looks like
> a have to use the right combination of V_0280A0_FORMAT, V_0280A0_NUMBER,
> V_0280A0_BLEND_CLAMP, V_0280A0_BLEND_BYPASS etc, but I just keep having
> strange artefacts every n pixel (for example R32_FLOAT only renders the
> even rows correctly).
>

Yeah, you'd need to sort out the state properly for these new formats.

Alex

> Any help with this would be really appreciated.
>
> Regards,
> Christian.
>
>