i965: Mark the workaround BO with EXEC_OBJECT_WRITE in BLORP.

Submitted by Kenneth Graunke on Jan. 23, 2018, 9:28 a.m.

Details

Message ID 20180123092820.9742-1-kenneth@whitecape.org
State New
Headers show
Series "i965: Mark the workaround BO with EXEC_OBJECT_WRITE in BLORP." ( rev: 1 ) in Mesa

Not browsing as part of any series.

Commit Message

Kenneth Graunke Jan. 23, 2018, 9:28 a.m.
The purpose of the workaround BO is to write to it.
---
 src/mesa/drivers/dri/i965/genX_blorp_exec.c | 1 +
 1 file changed, 1 insertion(+)

Patch hide | download patch | download mbox

diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 062171af600..237ab876abe 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -189,6 +189,7 @@  blorp_get_workaround_page(struct blorp_batch *batch)
 
    return (struct blorp_address) {
       .buffer = brw->workaround_bo,
+      .reloc_flags = RELOC_WRITE,
    };
 }
 #endif

Comments

Quoting Kenneth Graunke (2018-01-23 09:28:20)
> The purpose of the workaround BO is to write to it.

Do you care for the serialisation here? I thought the purpose of the wa
was just for write-only memory, so lying to the kernel to disable write
hazards is acceptable.
-Chris
On Tuesday, January 23, 2018 1:32:53 AM PST Chris Wilson wrote:
> Quoting Kenneth Graunke (2018-01-23 09:28:20)
> > The purpose of the workaround BO is to write to it.
> 
> Do you care for the serialisation here? I thought the purpose of the wa
> was just for write-only memory, so lying to the kernel to disable write
> hazards is acceptable.
> -Chris

We don't usually read it, so it should be fine, but I don't like lying
about things...it was more an oversight than an intentional way to avoid
synchronization.  What synchronization would there be, anyway, assuming
we don't ever read it or map it?

I thought we still read it for register checks, though it appears that
we now allocate a dedicated BO for that purpose.  Plus, screen creation
time is long done by the time we have a context and start using BLORP...

So basically, I don't like lying.  Is there really an advantage to it?
Quoting Kenneth Graunke (2018-01-24 04:57:20)
> On Tuesday, January 23, 2018 1:32:53 AM PST Chris Wilson wrote:
> > Quoting Kenneth Graunke (2018-01-23 09:28:20)
> > > The purpose of the workaround BO is to write to it.
> > 
> > Do you care for the serialisation here? I thought the purpose of the wa
> > was just for write-only memory, so lying to the kernel to disable write
> > hazards is acceptable.
> > -Chris
> 
> We don't usually read it, so it should be fine, but I don't like lying
> about things...it was more an oversight than an intentional way to avoid
> synchronization.  What synchronization would there be, anyway, assuming
> we don't ever read it or map it?

We share the w/a bo on the screen, iirc, so there may be unexpected
ordering between contexts. (Writes are strongly ordered, reads weakly,
i.e. 2 reads may be executed in either order.)
-Chris