How about assuming for each CS that it can use the compute ring and as
soon as we submit a PM4 command that can only be executed on the
graphics ring note that this CS needs to be executed on the graphics ring?
Just an idea,
Christian.
Am 25.09.2014 um 21:02 schrieb Tom Stellard:
On Mon, Sep 22, 2014 at 09:48:43PM +0200, Marek Olšák wrote:
No, we cannot detect compute-only contexts yet. We need to add a new
parameter to pipe_context::context_create which says that a context is
compute-only. That should be OpenCL but not OpenGL.
Also, some code paths like resource_copy_region use the graphics
engine for copying, which cannot be used with compute rings and must
be implemented with either DMA or compute-based blits. DMA isn't
flexible enough, so some additional work for compute-based blits might
be needed. We can also use the graphics ring for copying only and the
compute ring for compute stuff.
If possible, I think I would prefer continuing to use the graphic ring
for blits and only submit compute specific packets to the compute ring.
I'm a little concerned that adding a compute-flag to context create
might make it harder to share code between compute and graphics, which
I think is important.
What are the downsides of using both rings at once? Will we need to add
synchronization code for the two rings? I think the last time I
looked into doing this, the biggest problem was that fences were
submitted via the graphics ring even though they were meant for jobs
on the compute ring. Is there are good solution to this?
-Tom
Marek
On Mon, Sep 22, 2014 at 8:03 PM, Niels Ole Salscheider
<niels_...@salscheider-online.de> wrote:
On Monday 22 September 2014, 12:16:13, Alex Deucher wrote:
On Sat, Sep 20, 2014 at 6:11 AM, Marek Olšák <mar...@gmail.com> wrote:
From: Marek Olšák <marek.ol...@amd.com>
Looks good. Tom should probably take a look as well. As a further
improvement, it would be nice to be able to use the compute rings for
compute rather than gfx, but I'm not sure how much additional effort
it would take to clean that up.
This is completely untested but now that we can detect compute contexts
something like the attached patches might be sufficient...
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
---
src/gallium/drivers/radeonsi/si_compute.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c index 4b2662d..3ad9182 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -168,6 +168,7 @@ static void si_launch_grid(
uint32_t pc, const void *input)
{
struct si_context *sctx = (struct si_context*)ctx;
+ struct radeon_winsys_cs *cs = sctx->b.rings.gfx.cs;
struct si_compute *program = sctx->cs_shader_state.program;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
struct r600_resource *input_buffer = program->input_buffer;
@@ -184,8 +185,11 @@ static void si_launch_grid(
unsigned lds_blocks;
unsigned num_waves_for_scratch;
+ radeon_emit(cs, PKT3(PKT3_CONTEXT_CONTROL, 1, 0) |
PKT3_SHADER_TYPE_S(1)); + radeon_emit(cs, 0x80000000);
+ radeon_emit(cs, 0x80000000);
+
pm4->compute_pkt = true;
- si_cmd_context_control(pm4);
si_pm4_cmd_begin(pm4, PKT3_EVENT_WRITE);
si_pm4_cmd_add(pm4, EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH) |
--
1.9.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
