| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Unless e.g. PB_USAGE_DONTBLOCK or PB_USAGE_UNSYNCHRONIZED would be specified.
|
|
radeon_bo_pb_map_internal().
Having a non-NULL data pointer doesn't imply it's safe to reuse that mapping,
it may have been unmapped but not flushed yet.
|
|
|
|
|
|
Fixes this GCC warning.
r600_state2.c: In function 'r600_context_flush':
r600_state2.c:946: error: implicit declaration of function 'drmCommandWriteRead'
|
|
|
|
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>
|
|
this fixes evergreen gears again.
|
|
since the reference code relies on these being NULL.
|
|
long lived maps were getting removed when they shouldn't this
tries to avoid that problem by only adding to the flush list
on unmap.
|
|
this adds the bo caching layer and uses it for vertex/index/constant bos.
ctx needs to take references on hw bos so the flushing works okay, also
needs to flush the maps.
|
|
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.
|
|
caused by 0b9eb5c9bb03e5134d9a41786178100109e80c5a
test run glxgears, resize.
|
|
This fixes a DRM deadlock in the cubestorm xscreensaver, because somehow
there must not be 2 different BOs relocated in one CS if both BOs back
the same handle. I was told it is impossible to happen, but apparently
it is not, or there is something else wrong.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=30145
|
|
If the buffer we are attempting to map is referenced by the unsubmitted
command stream for this context, we need to flush the command stream,
however to do that we need to be able to access the context at the lowest
level map function, currently we set the buffer in the toplevel map, but this
racy between context. (we probably have a lot more issues than that.)
I'll look into a proper solution as suggested by jrfonseca when I get some time.
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
for evergreen I ended up using a non-contig array of states, but
this code needs a bit of fixing up to deal with that.
|
|
|
|
|
|
|
|
adds shader opcodes + assembler support (except ARL)
uses constant buffers
add interp instructions in fragment shader
adds all evergreen hw states
adds evergreen pm4 support.
this runs gears for me on my evergreen
|
|
the DDX and r600c both flush cb/db after the draw is emitted,
as long as they do that, r600g can't be different, as it races.
We end up with r600g flush, set CB, DDX set CB, flush. This
was causing misrendering on my evergreen, where sometimes the drawing
would go to an old CB.
|
|
the code should reloc correctly a single BO 3 times.
|
|
|
|
DX9 constants were in the constant file, and evergreen no longer support
cfile. r600/700 can also use constants in memory buffers, so add the code
(disabled for now) to enable that as precursor for evergreen.
|
|
This was inherently fragile as any changes to r600_states.h would also
need manual updating of all of the bits in radeon.h. Just add a simple
python script to do the conversion, its not hooked up to make at all.
This also will make adding evergreen a bit easier.
|
|
Previously bind sampler/sampler_view can be converted and endup
overwritting the current state we want to schedule. Example :
bind texA texB to sampler_view[0] & sampler_view[1], render,
bind texB to sampler_view[0] render. Now state associated to
texB are set to configure sampler_view slot 0, but as we don't
unbind sampler_view[1] still point to texB state so we end up
with sampler_view[1] overwritting sampler_view[0], which gives
wrong rendering if next rendering bind texA to sampler_view[0],
it will endup as texB is bound to sampler_view[0]. If you are
not confuse at that point give me a call i will be buying you
beer.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Make state statically allocated, this kills a bunch of code
and avoid intensive use of malloc/free. There is still a lot
of useless duplicate function wrapping that can be kill. This
doesn't improve yet performance, needs to avoid memcpy states
in radeon_ctx_set_draw and to avoid rebuilding vs_resources,
dsa, scissor, cb_cntl, ... states at each draw command.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
This reverts commit 1fa7245c348cb7aced81f1672140f64cb6450e2f.
Conflicts:
src/gallium/drivers/r600/r600_state.c
|
|
This reverts commit de0b76cab22caa9fc7260f80acb8f151ccced6c5, its pre-computes the texture state wrong,
you can't just use an array of levels, since you can have FBOs to depth texture slices inside a level as well
it would get really messy quickly. Probably need to split commits like this up into pieces for each piece
of state, so we can revert bits easier in case of regressions.
This also break 5 piglit tests, and valgrind starts to warn about invalid read/writes after this.
|
|
Idea is to build hw state at pipe state creation and
reuse them while keeping a non PM4 packet interface
btw winsys & pipe driver. This commit also force rebuild
of pm4 packet on each call to radeon_state_pm4 which
in turn slow down everythings, this will be addressed.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
The current states code had an unhealthy relationship between
that had to somehow magically align themselves, editing either
place meant renumbering all states after the one you were on,
and it was pretty unapproachable code.
This replaces the huge types structures with a simple type + sub
type struct, which is keyed on an stype enum in radeon.h. Each
stype can have a per-shader type subclassing (4 types supported,
PS/VS/GS/FS), and also has a number of states per-subtype. So you
have 256 constants per 4 shaders per one CONSTANT stype.
The interface from the driver is changed to pass in the tuple,
(stype, id, shader_type), and we look for this. If
radeon_state_shader ever shows up on profile, it could use a
hashtable based on stype/shader_type to speed things up.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
This reverts commit bd25e23bf3740f59ce8859848c715daeb9e9821f.
Apart from introducing a lot of hex magic numbers and being highly impenetable code,
it causes lots of lockups on an average piglit run that always runs without lockups.
Always run piglit before/after doing big things like this.
|
|
handle very early errors in pipe_screen creation (failure of
nouveau_screen_init in nv50_screen_create)
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Directly build PM4 packet, avoid using malloc (no states are
bigger than 128 dwords), remove unecessary informations,
remove pm4 building in favor of prebuild pm4 packet.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
There may actually be something mapped in that range, especially for large
buffers like e.g. the GL Drawable.
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
|
|
these events have names, use them.
|
|
Apart from the fact that the radeon.h/r600_states.h editing is a nightmare, this
wasn't so bad.
passes piglit user-clip test now also trivial tests.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
