It's easily reproducible with Compiz with its Resize window mode
set to Normal (which is usually not the default mode).
https://bugs.freedesktop.org/show_bug.cgi?id=28658https://bugs.freedesktop.org/show_bug.cgi?id=29303
This is actually a workaround to prevent Compiz crashes.
Instead, a completely white titlebar might show up during resizing
transparent windows (a rare case).
The underlying cause should be fixed by someone who has more knowledge
about the code. (dri2_drawable_get_buffers should not return NULL)
Acked-By: Jakob Bornecrantz <jakob@vmware.com>
Even though the spec says that the limits should be -64/+63, proprietary
drivers support much larger relative offsets and some applications do
depend on this non-standard behavior.
Also program_parse.tab.c has been regenerated.
This fixes the parser error:
ARB_vp: error: relative address offset too large
See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628
4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50.
It is not supposed to be a definite hardware limit, it is for the parser
not to get in the way and let the underlying driver decide whether it can
run the shader or not.
Make sure LIT fills all slot for instruction (can't do W instruction
without having the Z slot filled with at least a NOP).
ALU instruction can't access more than 4 constant, move constant to
temporary reg if we reach the limit.
Fix ALU block splitting, only split ALU after ALU with last instruction
bit sets.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
If texture coordinates come from the vertex shader, there are always
4 components in the rasterizer input packet, but if the coordinates
are stuffed (like for point sprites), there are only 2 or 3 components
(based on GB_ENABLE) and if we rasterize more, it locks up.
When DRI2 swap buffer is pending (copy buffer not pageflipping)
we need to make sure we have the flush extension so radeon doesn't
resume rendering on the not yet blitted front buffer.
Modified version of Jerome's patch to add flush extension
in the correct place.
This prepares a possible fix for:
https://bugs.freedesktop.org/show_bug.cgi?id=28341https://bugs.freedesktop.org/show_bug.cgi?id=28410
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
r600 doesnt need the same normalization as r700 - instead it requires
range to be truncated to -pi..pi
I left the range trunc also effective on r700 althouch according the docs
it has sufficent range (-512*PI, +512*PI). The instructions seem
to be used not too often to cause perf loss because of this
Based on patches and testing by Conn Clark and Alain Perrot
mtypes.h does not use any symbols from compiler.h.
Also add the required headers for files that depended on symbols from
compiler.h but were indirectly including compiler.h through mtypes.h.
Marek Olšák
Jerome Glisse
Zack Rusin
Vinson Lee
Mario Kleiner
Kristian Høgsberg
Andre Maasikas
Michal Krol
Dave Airlie
Chia-I Wu