Ah, perhaps, yes. My bad.
On Tue, Sep 17, 2019 at 12:18:17AM +0200, Boris Brezillon wrote:
> 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
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
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 =
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
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
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
