It's the same as in r600g.
I can't merge si_atom with si_pm4_state, because the latter is too big and
isn't even driven by the dirty flag. Also I'm gonna share the whole streamout
state handling with r600g (just one atom though) and therefore I need the same
interface. The advantage is that almost
On Thu, Aug 8, 2013 at 2:55 PM, Christian König wrote:
> Am 08.08.2013 14:02, schrieb Marek Olšák:
>
>> Why is the order so important? Note that cache flushes shouldn't be
>> treated like states and neither should the draw packets and any state
>> that comes from pipe_draw_info. The only things le
Am 08.08.2013 14:02, schrieb Marek Olšák:
Why is the order so important? Note that cache flushes shouldn't be
treated like states and neither should the draw packets and any state
that comes from pipe_draw_info. The only things left are the register
updates and resource updates where the order do
Why is the order so important? Note that cache flushes shouldn't be
treated like states and neither should the draw packets and any state
that comes from pipe_draw_info. The only things left are the register
updates and resource updates where the order doesn't matter, does it?
Anyway, the order is
Am 08.08.2013 02:20, schrieb Marek Olšák:
It's the same as in r600g. Look how simple it is.
That concept has the problem that we don't necessary know in which order
the state is emitted.
Why not just add an "emit" callback to si_pm4_state for the short term
instead?
For the long term we s
It's the same as in r600g. Look how simple it is.
---
src/gallium/drivers/radeonsi/r600_hw_context.c | 8
src/gallium/drivers/radeonsi/radeonsi_pipe.h | 9 +
src/gallium/drivers/radeonsi/si_state.h| 10 ++
src/gallium/drivers/radeonsi/si_state_draw.c | 8 +++
