Signed-off-by: Matwey V. Kornilov
---
src/egl/opengl/eglinfo.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/egl/opengl/eglinfo.c b/src/egl/opengl/eglinfo.c
index c24f7682..76152af8 100644
--- a/src/egl/opengl/eglinfo.c
+++ b/src/egl/opengl/eglinfo.c
@@ -234,6 +234,10 @@ main(int ar
https://bugs.freedesktop.org/show_bug.cgi?id=111577
--- Comment #4 from Marius Vlad ---
This seems to happen only when resizing the window before having a change to
flip the back/current buffers. Pushed I fix which works but not sure if fixes
the problem at the correct level:
https://gitlab.free
Hello,
This is the second attempt at supporting batch pipelining. This time I
implemented it using a dependency graph (as suggested by Alyssa and
Steven) so that batch submission can be delayed even more: the only
time we flush batches now is when we have an explicit flush or when
the CPU needs to
Some BOs are used by batches but never explicitly added to the BO set.
This is currently not a problem because we wait for the execution of
a batch to be finished before releasing a BO, but we will soon relax
this rule.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.
The DRM driver expects an array of u32, let's use the correct type, even
if using an int works in practice because it's still a 32-bit integer.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gall
That's what we do for other per-batch BOs, and we'll soon add an helper
to automate this create_bo()+add_bo()+bo_unreference() sequence, so
let's prepare the code to ease this transition.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c | 1 -
src/gallium/drivers/panfro
panfrost_{create,free,get}_batch() are only called inside pan_job.c.
Let's make them static.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 6 +++---
src/gallium/drivers/panfrost/pan_job.h | 11 ---
2 files changed, 3 insertions(+), 14 deletions(-)
diff --g
Change the prefix for BO allocation flags to make it consistent with
the rest of the BO API.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_assemble.c | 2 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 2 +-
src/gallium/drivers/panfrost/pan_bo.c| 12 ++
This will allow us to only flush batches touching a specific resource,
which is particularly useful when the CPU needs to access a BO.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 31 ++
src/gallium/drivers/panfrost/pan_job.h | 4
2 fi
So we can store the flags as data and keep the BO as a key. This way
we keep track of the type of access done on BOs.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 33 +-
src/gallium/drivers/panfrost/pan_job.h | 2 +-
2 files changed, 23 ins
So we can implement fine-grained dependency tracking between batches.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 51 ++
src/gallium/drivers/panfrost/pan_job.h | 39
2 files changed, 90 insertions(+)
diff --git a/src/g
Now that we have track inter-batch dependencies, the flush done in
panfrost_set_framebuffer_state() is no longer needed. Let's get rid of
it.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 46 ++
1 file changed, 3 insertions(+), 43 deletions(-
panfrost_bo_mmap() already takes care of that.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_resource.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index
panfrost_bo_unreference() should be used instead.
The only difference caused by this change is that the scratchpad,
tiler_heap and tiler_dummy BOs are now returned to the cache instead
of being freed when a context is destroyed. This is only a problem if
we care about context isolation, which appa
Will be useful to make the ioctl(WAIT_BO) call conditional on BOs that
are not exported/imported (meaning that all GPU accesses are known
by the context).
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 4 ++--
src/gallium/drivers/panfrost/pan_bo.h | 6 ++
2 files
The idea is to track which BO are being accessed and the type of access
to determine when a dependency exists. Thanks to that we can build a
dependency graph that will allow us to flush batches in the correct
order.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h |
Right now, the BO API is spread over pan_{allocate,resource,screen}.h.
Let's move all BO related definitions to a separate header file.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 1 +
src/gallium/drivers/panfrost/pan_allocate.h | 20
src/gallium/
We are about to add a batch queue to keep track of submission order.
Let's rename the existing batches hash table (which is used to get the
batch attached to an FBO) into fbo_to_batch to avoid confusion.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
src/g
We don't have to flush all batches when we're only interested in
reading/writing a specific BO. Thanks to the
panfrost_flush_batches_accessing_bo() and panfrost_bo_wait() helpers
we can now flush only the batches touching the BO we want to access
from the CPU.
Signed-off-by: Boris Brezillon
---
We'll soon need to freeze a batch not only when it's flushed, but also
when another batch depends on us, so let's add a helper to avoid
duplicating the logic.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 62 ++
1 file changed, 44 insertions(
has_draws can be inferred directly from the batch->last_job value, no
need to pass it around.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c| 3 ++-
src/gallium/drivers/panfrost/pan_job.c| 4 +---
src/gallium/drivers/panfrost/pan_screen.h | 2 +-
3 files change
pan_drm.c was only meaningful when we were supporting 2 kernel drivers
(mali_kbase, and the drm one). Now that there's now kernel-driver
abstraction we're better off moving those functions were they belong:
* BO related functions in pan_bo.c
* fence related functions + query_gpu_version() in pan_s
We don't know who else is using the BO in that case, and thus shouldn't
re-use it for something else.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 5 +
src/gallium/drivers/panfrost/pan_bo.h | 4
2 files changed, 9 insertions(+)
diff --git a/src/gallium/dri
And use it in panfrost_flush() to flush all batches, and not only the
one currently bound to the context.
We also replace all internal calls to panfrost_flush() by
panfrost_flush_all_batches() ones.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_compute.c | 2 +-
src/gall
This way we have all BO related functions placed in the same source
file.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 20
src/gallium/drivers/panfrost/pan_resource.c | 19 ---
2 files changed, 20 insertions(+), 19 deletion
Store a screen pointer in panfrost_bo so we don't have to pass a screen
object to all functions manipulating the BO.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 2 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 2 +-
src/gallium/drivers/panfrost/pan_bo.
The panfrost_fence logic currently waits on the last submitted batch,
but the batch serialization that was enforced in
panfrost_batch_submit() is about to go away, allowing for several
batches to be pipelined, and the last submitted one is not necessarily
the one that will finish last.
We need to
This is not strictly required, but let's try to match the draw call
orders, just in case the app had a reason to do it in this order.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 6 ++
src/gallium/drivers/panfrost/pan_job.c | 23 +++---
ctx is allocated with rzalloc() which takes care of zero-ing the memory
region. No need to call memset(0) on top.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gal
All dEQP-GLES2.functional.fbo.render.texsubimage.* tests are now
passing.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt
b/src/gallium/drivers/p
If we want the batch dependency tracking to work correctly we must
make sure all BOs are added to the batch->bos set early enough. Adding
FBO BOs when generating the fragment job is clearly to late. Add a
panfrost_batch_add_fbo_bos helper and call it in the clear/draw path.
Signed-off-by: Boris Br
We just replace the per-context out_sync object by a pointer to the
the fence of the last last submitted batch. Pipelining of batches will
come later.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 6 --
src/gallium/drivers/panfrost/pan_context.h | 3 ++-
s
This is needed if we want to free the panfrost_batch object at submit
time in order to not have to GC the batch on the next job submission.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 78 +++
src/gallium/drivers/panfrost/pan_bo.h | 2 +
2 f
Thanks to that we avoid the recursive call into panfrost_bo_create()
and we can get rid of panfrost_bo_release() by inlining the code in
panfrost_bo_unreference().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 146 --
1 file changed, 69 insert
This helper automates the panfrost_bo_create()+panfrost_batch_add_bo()+
panfrost_bo_unreference() sequence that's done for all per-batch BOs.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 9 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 8 ++---
src/
If we want to execute several batches in parallel they need to have
their own tiler and scratchpad BOs. Let move those objects to
panfrost_batch and allocate them on a per-batch basis.
Signed-off-by: Boris Brezillon
---
Note to Alyssa: I tried removing the dummy_tiler BO replacing it by a
dummy v
This way we can avoid calling ioctl(WAIT_BO) when we already know the
BO is idle because it hasn't been touched by a GPU job or because the
previous call to panfrost_bo_wait() returned true.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 40 +++---
The type of access being done on a BO has impacts on job scheduling
(shared resources being written enforce serialization while those
being read only allow for job parallelization) and BO lifetime (the
fragment job might last longer than the vertex/tiler ones, if we can,
it's good to release BOs ea
They are not expected to be called directly, users should use
panfrost_bo_{create,release}() instead.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 4 ++--
src/gallium/drivers/panfrost/pan_bo.h | 6 --
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git
Now that we have all the pieces in place to support pipelining batches
we can get rid of the drmSyncobjWait() at the end of
panfrost_batch_submit().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/src/gallium/d
As a drive-by comment, in case you didn't know, the "standard"
solution for avoiding flushing when BO's are written by the CPU (e.g.
uniform buffer updates) as documented in ARM's performance guide is to
add a copy-on-write mechanism, so that you have "shadow" BO's when the
original BO is modified
On Mon, 16 Sep 2019 17:11:01 +0700
Connor Abbott wrote:
> As a drive-by comment, in case you didn't know, the "standard"
> solution for avoiding flushing when BO's are written by the CPU (e.g.
> uniform buffer updates) as documented in ARM's performance guide is to
> add a copy-on-write mechanism
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Bug 111444 depends on bug 111450, which changed state.
Bug 111450 Summary: SPIR-V shader causes assertion failure `!"Unsupported deref
type"' in ir_build_deref_offset
https://bugs.freedesktop.org/show_bug.cgi?id=111450
What|Remov
https://bugs.freedesktop.org/show_bug.cgi?id=111698
Bug ID: 111698
Summary: system crash potentially due to mesa.
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
Reviewed-by: Alyssa Rosenzweig
On Mon, Sep 16, 2019 at 11:36:39AM +0200, Boris Brezillon wrote:
> panfrost_{create,free,get}_batch() are only called inside pan_job.c.
> Let's make them static.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_job.c | 6 +++---
> src/
Reviewed-by: Alyssa Rosenzweig
On Mon, Sep 16, 2019 at 11:36:40AM +0200, Boris Brezillon wrote:
> The DRM driver expects an array of u32, let's use the correct type, even
> if using an int works in practice because it's still a 32-bit integer.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gal
Reviewed-by: Alyssa Rosenzweig
On Mon, Sep 16, 2019 at 11:36:41AM +0200, Boris Brezillon wrote:
> Some BOs are used by batches but never explicitly added to the BO set.
> This is currently not a problem because we wait for the execution of
> a batch to be finished before releasing a BO, but we wi
R-b
On Mon, Sep 16, 2019 at 11:36:44AM +0200, Boris Brezillon wrote:
> has_draws can be inferred directly from the batch->last_job value, no
> need to pass it around.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_drm.c| 3 ++-
> src/gallium/drivers/panfrost/pan
R-b'
On Mon, Sep 16, 2019 at 11:36:43AM +0200, Boris Brezillon wrote:
> ctx is allocated with rzalloc() which takes care of zero-ing the memory
> region. No need to call memset(0) on top.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_context.c | 1 -
> 1 file chang
Reviewed-by: Alyssa Rosenzweig
> That's what we do for other per-batch BOs, and we'll soon add an helper
> to automate this create_bo()+add_bo()+bo_unreference() sequence, so
> let's prepare the code to ease this transition.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfro
https://bugs.freedesktop.org/show_bug.cgi?id=111698
--- Comment #1 from Jaap Aarts ---
I tried all mesa versions back to 19.0.0 and they all crashed, but I would like
to keep this open until it is fixed if possible.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You
R-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
On Mon, Sep 16, 2019 at 11:36:46AM +0200, Boris Brezillon wrote:
> This way we have all BO related functions placed in the same source
> file.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_bo.c | 20
> src/gallium/drivers/panfrost/pan_
I like removing DRM.
R-b.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
On Mon, Sep 16, 2019 at 11:36:49AM +0200, Boris Brezillon wrote:
> They are not expected to be called directly, users should use
> panfrost_bo_{create,release}() instead.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_bo.c | 4 ++--
> src/gallium/drivers/panfros
R-b
On Mon, Sep 16, 2019 at 11:36:50AM +0200, Boris Brezillon wrote:
> panfrost_bo_mmap() already takes care of that.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_resource.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/gallium
R-b, this is a nice cleanup and can probably prevent some WATs down the
line.
On Mon, Sep 16, 2019 at 11:36:51AM +0200, Boris Brezillon wrote:
> Store a screen pointer in panfrost_bo so we don't have to pass a screen
> object to all functions manipulating the BO.
>
> Signed-off-by: Boris Brezillo
> The only difference caused by this change is that the scratchpad,
> tiler_heap and tiler_dummy BOs are now returned to the cache instead
> of being freed when a context is destroyed.
That sounds fine to me.
> This is only a problem if
> we care about context isolation, which apparently is not t
R-b, I think
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b. Wonder why this never broke anything else either.
On Mon, Sep 16, 2019 at 11:36:54AM +0200, Boris Brezillon wrote:
> We don't know who else is using the BO in that case, and thus shouldn't
> re-use it for something else.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfro
R-b, I suppose. I wish we could do away with this kernel traffic as
discussed, though.
On Mon, Sep 16, 2019 at 11:36:55AM +0200, Boris Brezillon wrote:
> This is needed if we want to free the panfrost_batch object at submit
> time in order to not have to GC the batch on the next job submission.
>
R-b, but could we move this patch before the one adding the WAIT_BO? And
I guess some succeeding patches we'll want to move before as well, and
then the final one using it get squashed? Let's see.
On Mon, Sep 16, 2019 at 11:36:56AM +0200, Boris Brezillon wrote:
> Will be useful to make the ioctl(W
R-b, wonderful
On Mon, Sep 16, 2019 at 11:36:57AM +0200, Boris Brezillon wrote:
> This helper automates the panfrost_bo_create()+panfrost_batch_add_bo()+
> panfrost_bo_unreference() sequence that's done for all per-batch BOs.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfro
R-b
On Mon, Sep 16, 2019 at 11:36:58AM +0200, Boris Brezillon wrote:
> If we want the batch dependency tracking to work correctly we must
> make sure all BOs are added to the batch->bos set early enough. Adding
> FBO BOs when generating the fragment job is clearly to late. Add a
> panfrost_batch_a
> Note to Alyssa: I tried removing the dummy_tiler BO replacing it by a
> dummy value (tried both 0xdeafbeef and 0x0) and unfortunately it
> crashed, so I decided to keep this dummy allocation for now.
Very well. That'd be a neat but very low prio RE task, so *shrug*
> -static void
> -panfrost_se
https://bugs.freedesktop.org/show_bug.cgi?id=111590
tempel.jul...@gmail.com changed:
What|Removed |Added
CC||tempel.jul...@gmail.com
--
Yo
PAN_BO_GPU_ACCESS_* is rather wordy. We're a GPU driver, of course it's
GPU access :)
Could we just do PAN_BO_ACCESS_* instead?
> static mali_ptr
> panfrost_upload_tex(
> struct panfrost_context *ctx,
> +enum pipe_shader_type st,
> struct panfrost_sampler_view *view)
>
What if flags = 0?
On Mon, Sep 16, 2019 at 11:37:01AM +0200, Boris Brezillon wrote:
> So we can store the flags as data and keep the BO as a key. This way
> we keep track of the type of access done on BOs.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_job.c | 33 ++
> +/* If ->gpu_access is 0, the BO is idle, and if the WRITE
> flag
> + * is cleared, that means we only have readers.
> + */
> +if (!bo->gpu_access)
> +return true;
> +else if (!(access_type &
On Mon, 16 Sep 2019 09:59:15 -0400
Alyssa Rosenzweig wrote:
> PAN_BO_GPU_ACCESS_* is rather wordy. We're a GPU driver, of course it's
> GPU access :)
Well, the driver can also do CPU accesses to the same BOs :P.
>
> Could we just do PAN_BO_ACCESS_* instead?
I guess that's fine as long as it's
On Mon, 16 Sep 2019 10:00:13 -0400
Alyssa Rosenzweig wrote:
> What if flags = 0?
Not sure what you have in mind. 0 would be a valid value (though not
really useful since that just means the BO is private and we don't give
any information on the type of access done on this BO). If you're
worried
On Mon, 16 Sep 2019 10:05:52 -0400
Alyssa Rosenzweig wrote:
> > +/* If ->gpu_access is 0, the BO is idle, and if the WRITE
> > flag
> > + * is cleared, that means we only have readers.
> > + */
> > +if (!bo->gpu_access)
> > +
On Sun, 2019-09-15 at 17:53 +0300, Matwey V. Kornilov wrote:
> Signed-off-by: Matwey V. Kornilov
Thanks! I had an equivalent hack in my local copy and hadn't pushed it,
tsk tsk. I've opened a merge request for yours here:
https://gitlab.freedesktop.org/mesa/demos/merge_requests/4
Will merge in
https://bugs.freedesktop.org/show_bug.cgi?id=111300
tempel.jul...@gmail.com changed:
What|Removed |Added
CC||tempel.jul...@gmail.com
--
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=111300
--- Comment #1 from tempel.jul...@gmail.com ---
Might due to Async Compute, which affects the Mesa overlay as well:
https://bugs.freedesktop.org/show_bug.cgi?id=111401
On Windows, the Steam fps counter doesn't flicker, but instead reduces
perfor
> > PAN_BO_GPU_ACCESS_* is rather wordy. We're a GPU driver, of course it's
> > GPU access :)
>
> Well, the driver can also do CPU accesses to the same BOs :P.
Yes, but we won't be marking them off this way ever, no?
> > > +panfrost_batch_add_bo(batch, rsrc->bo,
> > > +
Well, the hash tables strongly assume you're not using NULLs for things.
See _mesa_hash_table_set_deleted_key for how to change that behaviour.
On Mon, Sep 16, 2019 at 04:17:37PM +0200, Boris Brezillon wrote:
> On Mon, 16 Sep 2019 10:00:13 -0400
> Alyssa Rosenzweig wrote:
>
> > What if flags =
> > > +/* If ->gpu_access is 0, the BO is idle, and if the
> > > WRITE flag
> > > + * is cleared, that means we only have readers.
> > > + */
> > > +if (!bo->gpu_access)
> > > +return true;
> > > +
> +/* Start in a signaled state so that even non-submitted batches
> + * (those that have no draw/clear) can be waited upon.
> + */
When would this happen? Presumably if a batch does nothing whatsoever,
it doesn't make sense to wait on it.
> #include "pan_resource.h"
>
>
Also, some typos:
> + * since other batches might want to wait on an fence of already
a fence.
> +/* panfrost_batch_fence is the out fence of batch that users or other batches
a batch
> +/* Cached value of the signaled state to avoid calling WAIC_SYNCOBJs
WAIT_SYNCOBJs
___
R-b
On Mon, Sep 16, 2019 at 11:37:04AM +0200, Boris Brezillon wrote:
> We just replace the per-context out_sync object by a pointer to the
> the fence of the last last submitted batch. Pipelining of batches will
> come later.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfro
> +/* Remove the entry in the FBO -> batch hash table if the batch
> + * matches. This way, next draws/clears targeting this FBO will
> trigger
> + * the creation of a new batch.
> + */
> +entry = _mesa_hash_table_search(ctx->batches, &batch->key);
> + i
> + * A BO is either being written or read at any time, that's what the type
> field
> + * encodes.
Might this be inferred from (writer != NULL) and (readers->length > 0)?
> +util_dynarray_foreach(&batch->dependencies,
> + struct panfrost_batch_fence *, dep)
> +/* Export fences from all pending pending batches. */
Pending pending batches, from the Department of Redundancy Department.
Aside from that, R-b :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailma
> diff --git a/src/gallium/drivers/panfrost/pan_compute.c
> b/src/gallium/drivers/panfrost/pan_compute.c
> index 4639c1b03c38..036dffbb17be 100644
> --- a/src/gallium/drivers/panfrost/pan_compute.c
> +++ b/src/gallium/drivers/panfrost/pan_compute.c
> @@ -133,7 +133,7 @@ panfrost_launch_grid(struct
> As a drive-by comment, in case you didn't know, the "standard"
> solution for avoiding flushing when BO's are written by the CPU (e.g.
> uniform buffer updates) as documented in ARM's performance guide is to
> add a copy-on-write mechanism, so that you have "shadow" BO's when the
> original BO is
On Mon, 16 Sep 2019 15:38:10 -0400
Alyssa Rosenzweig wrote:
> > +/* Start in a signaled state so that even non-submitted batches
> > + * (those that have no draw/clear) can be waited upon.
> > + */
>
> When would this happen? Presumably if a batch does nothing whatsoeve
On Mon, 16 Sep 2019 16:15:14 -0400
Alyssa Rosenzweig wrote:
> > + * A BO is either being written or read at any time, that's what the type
> > field
> > + * encodes.
>
> Might this be inferred from (writer != NULL) and (readers->length > 0)?
No, I need to keep the old writer around when the
On Mon, 16 Sep 2019 16:29:05 -0400
Alyssa Rosenzweig wrote:
> > As a drive-by comment, in case you didn't know, the "standard"
> > solution for avoiding flushing when BO's are written by the CPU (e.g.
> > uniform buffer updates) as documented in ARM's performance guide is to
> > add a copy-on-wri
On Mon, 16 Sep 2019 15:26:12 -0400
Alyssa Rosenzweig wrote:
> Well, the hash tables strongly assume you're not using NULLs for things.
>
> See _mesa_hash_table_set_deleted_key for how to change that behaviour.
Maybe I'm missing something, but AFAICT it's the key field that requires
special care
> How about something simple like this instead:
>
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> b/src/mesa/state_tracker
> index d6a0264..4f5acfd 100644
> --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> @@ -687,9 +687,14 @@ st_lin
https://bugs.freedesktop.org/show_bug.cgi?id=111679
--- Comment #4 from Shmerl ---
Still happens on latest Mesa master. Should I make a MR in Gitlab for the fix?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Bug 111444 depends on bug 111339, which changed state.
Bug 111339 Summary: [Debug mesa]. Dirt 4 crashes after launching
https://bugs.freedesktop.org/show_bug.cgi?id=111339
What|Removed |Added
--
94 matches
Mail list logo
