| Age | Commit message (Collapse) | Author |
|---|
|
This bug can be triggered by rendering polygons with
glProvokingVertexEXT(GL_FIRST_VERTEX_CONVENTION_EXT);
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
|
|
|
|
The BGNLOOP and ENDLOOP instructions are now being used correctly, which
makes break and continue possible. The deadcode pass has been modified to
handle breaks, and the compiler is more careful about which loops are
unrolled.
|
|
|
|
|
|
|
|
|
|
This stops us advertising lots of ms visuals we can't actually use.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
When we have instance divisors we don't really know which vertex
elements we'll be fetching ahead of time.
This fixes a bug in instanced drawing which was exposed by the new
draw_vbo() code because of max_index not being ~0 as often as it used
to be. The test for max_index >= DRAW_PIPE_MAX_VERTICES often hid
this problem before.
|
|
Plus more debug code and do clamping in generic_run().
|
|
|
|
|
|
|
|
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=28658
https://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.
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
|
|
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
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>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29372
|
|
|
|
Include glheader.h for GLenum symbol.
|
|
Include compiler.h for CONST symbol.
Remove config.h as m_xform.h uses no additional symbols from config.h.
|
|
m_translate.h does not use any additional symbols added by config.h.
|
|
|
|
texgen.h doesn't use any symbols additionally added by mtypes.h.
|
|
texcompress_fxt1.h doesn't use any additional symbols added by mtypes.h.
|
|
syncobj.h doesn't use any additional symbols that is added by context.h.
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
When a DRI2 swap buffer is pending we need to make sure we
have the flush extension so radeon doesn't resume rendering to
or reading from the not yet blitted front buffer.
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28341
https://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>
|
|
This reverts commit 8446f257b3e3ca4a3eb2c79bc357e46343e04e87.
|
|
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=28341
https://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
|
|
Apparently, we must always use integers to perform calculations,
otherwise the results won't match D3D's CxV8U8 definition.
|
|
|
|
|
|
migrates cb_cntl to be regenerated
|
|
|
|
this isn't used anywhere else yet.
|
|
Not sure if this will actually fix the issue, but it fixes the warning.
|
|
Getting tiling right has always been tricky.
There are so many subtle details...
|
|
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.
|
|
|
|
|
