| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
we were leaking buffers since the flush code was added, it wasn't dropping references.
move setting up flush to the set_framebuffer_state.
clean up the flush state object.
make more space in the BOs array for flushing.
|
|
this just uses the common code from r300g now in util to do translations on r600g.
|
|
These can be used by other drivers, like r600g.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
This reverts commit a1d9a58b825825723f1c5f7705f2ed3ef834038a.
Flushing the upload buffers on draw is wrong, uploads aren't supposed to
cause flushes in the first place. The real issue was
radeon_bo_pb_map_internal() not respecting PB_USAGE_UNSYNCHRONIZED.
|
|
Unless e.g. PB_USAGE_DONTBLOCK or PB_USAGE_UNSYNCHRONIZED would be specified.
|
|
radeon_ws_bo_map() will already take care of that if needed.
|
|
If a upload buffer is used by a previous draw that's still in the CS,
accessing it would need a context flush. However, doing a context flush when
mapping the upload buffer would then flush/destroy the same buffer we're trying
to map there. Flushing the upload buffers before a draw avoids both the CS
flush and the upload buffer going away while it's being used. Note that
u_upload_data() could e.g. use a pool of buffers instead of allocating new
ones all the time if that turns out to be a significant issue.
|
|
|
|
On r6xx if an MOVA instruction is emitted we should set this bit.
|
|
This makes the 'glsl1-gl_FrontFacing var (1)' piglit test pass.
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
|
|
|
|
Fixes this GCC warning.
nv50_state_validate.c:336: warning: missing initializer
nv50_state_validate.c:336: error: (near initialization for 'validate_list[20].func')
|
|
|
|
|
|
|
|
|
|
|
|
Silences this GCC warning.
nvfx_vertprog.c: In function 'nvfx_vertprog_translate':
nvfx_vertprog.c:998: warning: assignment discards qualifiers from pointer target type
|
|
The variables are used in code that is currently ifdef'ed out.
|
|
|
|
|
|
Winsys context build a list of register block a register block is
a set of consecutive register that will be emited together in the
same pm4 packet (the various r600_block* are there to provide basic
grouping that try to take advantage of states that are linked together)
Some consecutive register are emited each in a different block,
for instance the various cb[0-7]_base. At winsys context creation,
the list of block is created & an index into the list of block. So
to find into which block a register is in you simply use the register
offset and lookup the block index. Block are grouped together into
group which are the various pkt3 group of config, context, resource,
Pipe state build a list of register each state want to modify,
beside register value it also give a register mask so only subpart
of a register can be updated by a given pipe state (the oring is
in the winsys) There is no prebuild register list or define for
each pipe state. Once pipe state are built they are bound to
the winsys context.
Each of this functions will go through the list of register and
will find into which block each reg falls and will update the
value of the block with proper masking (vs/ps resource/constant
are specialized variant with somewhat limited capabilities).
Each block modified by r600_context_pipe_state_set* is marked as
dirty and we update a count of dwords needed to emit all dirty
state so far.
r600_context_pipe_state_set* should be call only when pipe context
change some of the state (thus when pipe bind state or set state)
Then to draw primitive you make a call to r600_context_draw
void r600_context_draw(struct r600_context *ctx, struct r600_draw *draw)
It will check if there is enough dwords in current cs buffer and
if not will flush. Once there is enough room it will copy packet
from dirty block and then add the draw packet3 to initiate the draw.
The flush will send the current cs, reset the count of dwords to
0 and remark all states that are enabled as dirty and recompute
the number of dwords needed to send the current context.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
This is what xf86-video-ati and r600c do.
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
this add support for the upload manager for uploading user vbo/index buffers.
this provides a considerable speedup in q3 type games.
|
|
this moves to using a pb bufmgr instead of kernel bos directly.
|
|
this paves the way for moving to pb bufmgrs now.
|
|
introduce an abstraction layer between kernel bos and the winsys BOs.
this is to allow plugging in pb manager with minimal disruption to pipe driver.
|
|
no need for this info to be exported to pipe driver.
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29901
|
|
|
|
Allows disabling various operations (mainly texture-related, but
will grow) to try & identify bottlenecks.
Unlike LP_DEBUG, this is active even in release builds - which is
necessary for performance investigation.
|
|
|
|
|
|
This is likely only correct for OpenGL and not other state trackers.
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
We would leak the newly created bo if it cannot be mapped.
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
since the depth blit code is hardcoded hex yay \o/
|
|
This whole set of state just seems wrong, another cut-n-paste nightmare.
|
|
|
