Quoting Jason Ekstrand (2018-01-26 18:01:05)
> I wasn't suggesting that you use pread *instead* of stalling. But once you've
> stalled, nothing will be touching it. There is the possibility of another
> context or process of it's shared but mapping won't protect you from that
> either. I don't
In either case, please either map in both or pread/write in both.
On January 26, 2018 10:01:07 Jason Ekstrand wrote:
I wasn't suggesting that you use pread *instead* of stalling. But once
you've stalled, nothing will be touching it. There is the possibility of
another
I wasn't suggesting that you use pread *instead* of stalling. But once
you've stalled, nothing will be touching it. There is the possibility of
another context or process of it's shared but mapping won't protect you
from that either. I don't know what Chris was getting at.
On January 26,
Hi,
The main reason I went with map and invalidate is because the kernel on pread
will only wait on execbuffer2 calls that declare they are going to write to the
given GEM; there is the off-chance that a wild write might hit the padding of
a GEM and the function contract is to check the
On Fri, Jan 26, 2018 at 12:56 AM, wrote:
> From: Kevin Rogovin
>
> Signed-off-by: Kevin Rogovin
> Reviewed-by: Chris Wilson
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.c | 115
>
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
Reviewed-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 115 -
src/mesa/drivers/dri/i965/brw_bufmgr.h | 13
2 files
Quoting kevin.rogo...@intel.com (2018-01-09 12:21:29)
> From: Kevin Rogovin
>
> Signed-off-by: Kevin Rogovin
> ---
> +bool
> +brw_bo_padding_is_good(struct brw_bo *bo)
> +{
> + if (bo->padding_size > 0) {
> + struct drm_i915_gem_mmap
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 115 -
src/mesa/drivers/dri/i965/brw_bufmgr.h | 13
2 files changed, 127 insertions(+), 1 deletion(-)
diff