Needs to track this ourself since because we get into a race condition with
the dri_util.c code on make current when rendering to the front buffer.
This is what happens:
Old context is rendering to the front buffer.
App calls MakeCurrent with a new context. dri_util.c sets
drawable->driContextPriv to the new context and then calls the driver make
current. st/dri make current flushes the old context, which calls back into
st/dri via the flush frontbuffer hook. st/dri calls dri loader flush
frontbuffer, which calls invalidate buffer on the drawable into st/dri.
This is where things gets wrong. st/dri grabs the context from the dri
drawable (which now points to the new context) and calls invalidate
framebuffer to the new context which has not yet set the new drawable as its
framebuffers since we have not called make current yet, it asserts.
(cherry picked from commit 94ccc31ba4)
Conflicts:
src/gallium/state_trackers/dri/common/dri_context.c
Before we were looping to nr_samplers, which is the number of fragment
samplers, not vertex samplers.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
(cherry picked from commit d087cfaabf)
This fixes a potential failure when a begin/end_query is the first
thing to happen after flushing the scene.
NOTE: This is a candidate for the 7.10 and 7.9 branches.
(cherry picked from commit 42dbc2530b)
Create a constant int pointer to the C function, then cast it to the
function's type. This avoids using trampoline code which seem to be
inadvertantly freed by LLVM in some situations (which leads to segfaults).
The root issue and work-around were found by José.
NOTE: This is a candidate for the 7.10 branch
(cherry picked from commit ee16e97ed1)
fixes 34179.
Reported-by: Sense Hofstede
Requested-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When use_spoken is true, istart (the first vertex of this segment) is
replaced by i0 (the spoken vertex of the fan). There are still icount
vertices.
Thanks to Brian Paul for spotting this.
(cherry picked from commit abbb1c8f08)
From the r600 ISA:
Each ALU clause can lock up to four sets of constants
into the constant cache. Each set (one cache line) is
16 128-bit constants. These are split into two groups.
Each group can be from a different constant buffer
(out of 16 buffers). Each group of two constants consists
of either [Line] and [Line+1] or [line + loop_ctr]
and [line + loop_ctr +1].
For supporting more than 64 constants, we need to
break the code into multiple ALU clauses based
on what sets of constants are needed in that clause.
Note: This is a candidate for the 7.10 branch.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Can't get away from referencing upload buffer as after flush a vertex buffer
using the upload buffer might still be active. Likely need to simplify the
pipe_refence a bit so we don't waste so much cpu time in it.
candidates for 7.10 branch
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Note the support for non float vertex draw likely regressed need to
find what we want to do there.
candidates for 7.10 branches
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
The hardware supports zero stride just fine. This is a port
of 2af8a19831 from r300g.
NOTE: This is a candidate for both the 7.9 and 7.10 branches.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Based on a patch from Drill <drill87@gmail.com>.
NOTE: This is a candidate for the 7.10 branch.
(cherry picked from commit 88550083b3)
Conflicts:
src/gallium/drivers/r300/r300_context.c
Set window_bit only when the visual id is greater than zero. Correct
visual types. Skip slow configs as they are not relevant. Finally, do
not return duplicated configs.
(cherry picked from commit 445cb9e53b)
Even though a bound texture stays bound when calling set_fragment_sampler_views,
it must be assigned a new cache region depending on the occupancy of other
texture units.
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Thanks to Álmos <aaalmosss@gmail.com> for finding the bug in the code.
NOTE: This is a candidate for both the 7.9 and 7.10 branches.
(cherry picked from commit daffaca53e)
The hardware apparently does support a zero stride, so let's use it.
This fixes missing objects in ETQW, but might also fix a ton of other
similar-looking bugs.
NOTE: This is a candidate for both the 7.9 and 7.10 branches.
(cherry picked from commit 2af8a19831)
The RS690 memory controller prefers things to be on a different
boundary than the discrete GPUs, we had an attempt to fix this,
but it still failed, this consolidates the stride calculation
into one place and removes the really special case check.
This fixes gnome-shell and 16 piglit tests on my rs690 system.
NOTE: This is a candidate for both the 7.9 and 7.10 branches.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit d19b5cbd31)
Fixes piglit glx-shader-sharing crash.
When shaders are shared by multiple contexts, the shader's draw context
pointer may point to a previously destroyed context. Dereferencing the
context pointer will lead to a crash.
In this case, simply removing the flushing code avoids the crash (the
exec and sse shader paths don't flush here either).
There's a deeper issue here, however, that needs examination. Shaders
should not keep pointers to contexts since contexts might get destroyed
at any time.
NOTE: This is a candidate for the 7.10 branch (after this has been
tested for a while).
(cherry picked from commit becc4bb90c)
Allow important performance increase by doing hw specific implementation
of the upload manager helper. Drop the range flushing that is not hit with
this code (and wasn't with previous neither). Performance improvement are
mostly visible on slow CPU.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
r600g is up to a point where all small CPU cycle matter and pb* turn
high on profile. It's mostly because pb try to be generic and thus
trigger unecessary check for r600g driver. To avoid having too much
abstraction & too much depth in the call embedded everythings into
r600_bo. Make code simpler & faster. The performance win highly depend
on the CPU & application considered being more important on slower CPU
and marginal/unoticeable on faster one.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
R6XX GPU doesn't like to have two partial flush writting
back to memory in row without a prior flush of the pipeline.
Add PS_PARTIAL_FLUSH to flush all work between the CP and
the ES, GS, VS, PS shaders.
Thanks a lot to Alban Browaeys (prahal on irc) for investigating
this issue.
Signed-off-by: Alban Browaeys <prahal@yahoo.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
It's not always possible to preprocess the content of 3D_LOAD_VBPNTR
in a command buffer, because the offset to all vertex buffers (which
the packet depends on) is derived from the "start" parameter of draw_arrays
and the "indexBias" parameter of draw_elements, but we can at least lazily
make a command buffer for the case when offset == 0, which should occur
most of the time.
Avoid rebuilding constant shader state at each draw call,
factor out spi update that might change at each draw call.
Best would be to update spi only when revealent states
change (likely only flat shading & sprite point).
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Vertex elements change are less frequent than draw call, those to
avoid rebuilding fetch shader to often build the fetch shader along
vertex elements. This also allow to move vertex buffer setup out
of draw path and make update to it less frequent.
Shader update can still be improved to only update SPI regs (based
on some rasterizer state like flat shading or point sprite ...).
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
The preprocessor magic in mapi was nothing but obfuscation. Rewrite
mapi_abi.py to generate real C code.
This commit removes the hack added in
43121f2086.
