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.
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?).
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).
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?
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).
Any help with this would be really appreciated.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
