(where the results are used directly by the GPU and not
CPU).
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_bufmgr.c| 24 +++
src/mesa/drivers/dri/i965/brw_bufmgr.h| 2 ++
src/mesa/drivers/dri/i965/gen6_queryobj.c
Lots of places open-coded the assumed layout of the predicate/results
within the query object, replace those with simple helpers.
v2: Fix function decl style.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
.../drivers/dri/i965/brw_conditional_render.c | 10
Quoting mathias.froehl...@gmx.net (2018-11-23 08:07:29)
> From: Mathias Fröhlich
>
> Factor out vertex array setup routines from the array state atom.
> The factored functions will be used in feedback rendering in the
> next change.
>
> Signed-off-by: Mathias Fröhlich
> ---
> src/mesa/state_tr
Quoting Mathias Fröhlich (2018-11-23 17:14:45)
> Hi Chris,
>
> On Friday, 23 November 2018 16:12:38 CET Chris Wilson wrote:
> >
> > Something to note here is that valgrind reports
> > (piglit/bin/drawoverhead):
> >
> > ==492== Use of uninitialised valu
Quoting Chris Wilson (2018-10-24 09:40:08)
> If we hang the GPU and end up banning our context, we will no longer be
> able to submit and abort with an error (exit(1) no less). As we submit
> minimal incremental batches that rely on the logical context state of
> previous batches, we
Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> Hi Andrii,
>
> Although I think what these patches do makes sense, I think it's missing
> the bigger picture.
> There is a lot more state that gets lost if we have to revert all of the
> emitted commands.
> A quick look at brw_upload_pipeline_sta
Quoting andrey simiklit (2019-01-08 16:00:45)
> On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's mi
Quoting Kenneth Graunke (2019-01-08 20:17:01)
> On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > Hi Andrii,
> > >
> > > Although I think what these patches do makes sense, I think it
Quoting Kenneth Graunke (2018-02-27 00:05:46)
> +static bool
> +gem_supports_48b_addresses(int fd)
> +{
> + struct drm_i915_gem_exec_object2 obj = {
> + .flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS,
> + };
> +
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = (uintptr_
Quoting Kenneth Graunke (2018-02-26 23:54:59)
> When anything goes wrong with this code, dumping the validation list
> is a useful way to figure out what's happening.
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20
> 1 file changed, 20 insertions(+)
>
> I've now u
Quoting Kenneth Graunke (2018-02-26 23:55:00)
> This makes the name shorter in debug printouts. If "workaround_bo"
> is good enough for the code, it's probably good enough for debugging.
brw->wa_bo and "w/a"? :)
-Chris
___
mesa-dev mailing list
mesa-dev
Quoting Kenneth Graunke (2018-02-27 20:56:29)
> On Tuesday, February 27, 2018 12:35:32 AM PST Chris Wilson wrote:
> > Quoting Kenneth Graunke (2018-02-27 00:05:46)
> > > +static bool
> > > +gem_supports_48b_addresses(int fd)
> > > +{
> >
hat might
be fixed by this.
Anyway, my fault sorry,
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Quoting Kenneth Graunke (2018-03-01 23:39:54)
> I'd like to reuse the upload logic for a new program cache, but the
> buffers will need to have a different lifetime than the default
> uploader, and also some address space restrictions.
>
> This makes it a bit more like u_upload_mgr.
To be clear,
Quoting Kenneth Graunke (2018-03-02 08:44:56)
> On Thursday, March 1, 2018 4:16:13 PM PST Chris Wilson wrote:
> > Quoting Kenneth Graunke (2018-03-01 23:39:54)
> > > I'd like to reuse the upload logic for a new program cache, but the
> > > buffers will need to ha
Quoting Kenneth Graunke (2018-03-01 23:39:55)
> This should have no practical impact. For the default uploader, we
> don't really care, but for others, we may want to append more data
> as the GPU is reading existing data, which means we need async and
> persistent flags.
Ok.
R
Quoting Emil Velikov (2018-03-02 17:45:29)
> [Moving the thread from wayland-devel to mesa-dev]
>
> On 2 March 2018 at 15:03, Chris Wilson wrote:
> > Quoting Emil Velikov (2018-03-02 14:52:28)
> >> Hi Chris,
> >>
> >> On 1 March 2018 at 08:28, Chris Wils
Quoting Lionel Landwerlin (2018-03-08 15:42:53)
> +static void
> +read_gt_frequency(struct brw_context *brw,
> + struct brw_perf_query_object *obj)
> +{
> + const struct gen_device_info *devinfo = &brw->screen->devinfo;
> + uint32_t *start_reg = obj->oa.map + MI_FREQ_START_OFFS
er populated with the intel_tiled_memcpy
> > functions.
> >
> > Tiling/detiling with the cpu will be the only way to handle Yf/Ys
> > tiling, when support is added for those formats.
> >
> > v2: Compute extents properly in the x|y-rounded-down case (Chris Wilson)
> >
>
Quoting Lionel Landwerlin (2018-03-15 14:24:32)
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index 73a6c73f537..12d22e12eee 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensio
Quoting Tapani Pälli (2018-01-22 08:26:15)
> Reviewed-by: Tapani Pälli
>
> On 01/20/2018 02:29 AM, Chris Wilson wrote:
> > The forward port of commit 6d87500fe12e ("dri: Change
> > __DriverApiRec::CreateContext to take a struct for attribs") failed to
> > ad
Quoting Jason Ekstrand (2018-01-22 09:45:55)
> On Mon, Jan 22, 2018 at 1:22 AM, Chris Wilson
> wrote:
>
> Quoting Tapani Pälli (2018-01-22 08:26:15)
> > Reviewed-by: Tapani Pälli
> >
> > On 01/20/2018 02:29 AM, Chris Wilson wrote:
>
Quoting Tapani Pälli (2018-01-22 12:29:31)
> Signed-off-by: Tapani Pälli
1&2 Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
Quoting Scott D Phillips (2018-01-10 07:16:59)
> +/* Compute extent parameters for use with tiled_memcpy functions.
> + * xs are in units of bytes and ys are in units of strides. */
> +static inline void
> +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map *map,
> + un
Quoting Scott D Phillips (2018-01-23 14:42:43)
> TileY's low 6 address bits are: v1 v0 u3 u2 u1 u0
> Thus a cache line in the tiled surface is composed of a 2d area of
> 16x4 bytes of the linear surface.
>
> Add a special case where the area being copied is 4-line aligned
> and a multiple of 4-lin
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
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 k
"i965: Use I915_EXEC_NO_RELOC")
I did think we were already checking for a more recent kernel, oh well.
I checked that v3.9 is the first kernel to support I915_EXEC_NO_RELOC
Reviewed-by: Chris Wilson
but I'll leave it to some else to vouch for bumping the requirement.
-Chris
___
textdata bss dec hex filename
8852169 388752 671064 9911985 973eb1 lib/i965_dri.so
8852017 388752 671064 9911833 973e19
---
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 48 +-
1 file changed, 16 insertions(+), 32 deletions(-)
diff --git a/src/m
From: Scott D Phillips
Similar to the transformation applied to linear_to_ytiled, also align
each readback from the ytiled source to a cacheline (i.e. transfer a
whole cacheline from the source before moving on to the next column).
This will allow us to utilize movntqda (_mm_stream_si128) in a
su
Quoting Matt Turner (2018-02-07 20:42:15)
> On Wed, Feb 7, 2018 at 11:41 AM, Chris Wilson
> wrote:
> >textdata bss dec hex filename
> > 8852169 388752 671064 9911985 973eb1 lib/i965_dri.so
> > 8852017 388752 671064 9911833 973e19
> > ---
Quoting Scott D Phillips (2018-02-08 00:16:34)
> Chris Wilson writes:
>
> > From: Scott D Phillips
> >
> > Similar to the transformation applied to linear_to_ytiled, also align
> > each readback from the ytiled source to a cacheline (i.e. transfer a
> > wh
Quoting Scott D Phillips (2018-02-08 00:19:04)
> From: Kevin Rogovin
>
> Adds a new debug tool to pad each GEM BO allocated with (weak)
> pseudo-random noise values which are then checked after each
> batchbuffer dispatch to the kernel. This can be quite valuable to
> find diffucult to track down
n reset. The permanent semaphore is a
reservation_object (accessed via a bo), it is a volatile collection of
fences that serves as a communication channel between processes.
A synopsis of the differences and use would be invaluable.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
*/
> + semaphore->permanent.type = ANV_SEMAPHORE_TYPE_DUMMY;
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
onditional rendering.
> +*/
> + brw_emit_pipe_control_flush(brw, PIPE_CONTROL_FLUSH_ENABLE);
This flush waits for the previous flushes to retire. You need a CS stall
to wait for this flush to retire before doing the LRM. Unless the earlier
flushes used a post-sync write, there isn't a guarantee that memory is
coherent.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
over
the same performance penalty from earler atoms? Basically why bother to
enable this over wc mapping (no stalls for a contended, limited
resource) + detiling. (Just note that for detiling Y to WC you need to
use a temporary cacheable page, or rearrange the code to make sure the
reads/writes a
On Sun, Mar 12, 2017 at 06:19:17PM +0100, David Weinehall wrote:
> On Sun, Mar 12, 2017 at 01:21:12PM +0000, Chris Wilson wrote:
> > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote:
> > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has
> &
+ (const void *)(uintptr_t)bo->bo.gem_handle);
> + assert(entry);
> + _mesa_hash_table_remove(cache->bo_map, entry);
> +
> + pthread_mutex_unlock(&cache->mutex);
> +
> + if (bo->bo.map)
> + anv_gem_munmap(bo->bo.map, bo
On Wed, Mar 15, 2017 at 09:50:57AM +, Chris Wilson wrote:
> On Tue, Mar 14, 2017 at 10:43:07PM -0700, Jason Ekstrand wrote:
> > +void
> > +anv_bo_cache_release(struct anv_device *device,
> > + struct anv_bo_cache *cache,
> > +
On Wed, Mar 15, 2017 at 08:28:24AM -0700, Jason Ekstrand wrote:
>On Wed, Mar 15, 2017 at 5:21 AM, Chris Wilson
><[1]ch...@chris-wilson.co.uk> wrote:
>
> On Wed, Mar 15, 2017 at 09:50:57AM +, Chris Wilson wrote:
> > On Tue, Mar 14, 2017 at 10:43:07
On Wed, Mar 15, 2017 at 08:54:40AM -0700, Jason Ekstrand wrote:
>On Wed, Mar 15, 2017 at 8:37 AM, Chris Wilson
><[1]ch...@chris-wilson.co.uk> wrote:
>
> On Wed, Mar 15, 2017 at 08:28:24AM -0700, Jason Ekstrand wrote:
> > On Wed, Mar 15, 2017
er submitted alongside the batch?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
27;s safest to simply mark them non-coherent.
>
> Chris Wilson caught this problem and wrote a similar (though less
> aggressive) patch to solve it; the miptree code has since undergone
> a lot of refactoring so I had to rewrite it.
I checked that this does fixup the glamor framebuffer
Quoting Kenneth Graunke (2017-08-19 08:26:58)
> This involves a bunch of unnecessary copying, a batch flush, and
> state re-emission.
> ---
> src/mesa/drivers/dri/i965/brw_program_cache.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
> b
Quoting Jason Ekstrand (2017-08-19 23:07:48)
> "Alloc for render" is a terrible name for a flag because it means
> basically nothing. What the flag really does is allocate a busy BO
> which someone theorized at one point in time would be more efficient if
> you're planning to immediately render to
Quoting Kenneth Graunke (2017-08-22 21:47:54)
> This involves a bunch of unnecessary copying, a batch flush, and
> state re-emission.
> ---
> src/mesa/drivers/dri/i965/brw_program_cache.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
>
Quoting Lionel Landwerlin (2017-08-29 11:58:57)
> This allows us to deploy new configurations without touching the
> kernel.
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/mesa/drivers/dri/i965/brw_performance_query.c | 97
> ++-
> 1 file changed, 96 insertions(+), 1 delet
Quoting Kenneth Graunke (2017-08-29 22:28:38)
> Anvil already had code to copy between two buffer objects in the most
> efficient way possible, using large bpp copies, then smaller bpp copies.
>
> This patch moves that logic into BLORP as blorp_buffer_copy(), so we
> can reuse it in i965 as well.
Quoting Kenneth Graunke (2017-08-31 21:17:58)
> We can drop the meaningless "64" suffix - libdrm_intel originally had
> an "offset" field that was an "unsigned long" which was the wrong size,
> and we couldn't remove/alter that field without breaking ABI, so we had
> to add a uint64_t "offset64" fi
Quoting Kenneth Graunke (2017-08-31 21:18:00)
> It's only used in one file.
Series is
Reviewed-by: Chris Wilson
with just a quibble on patch 3.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org
Quoting Kenneth Graunke (2017-09-06 01:09:33)
> A couple issues remain: the series drops the malloc'd shadow copy of
> the batch for non-LLC systems. I haven't checked how dire this is.
> The last patch also dramatically impacts batch sizes, which we'll need
> to benchmark. However, I thought I'd
in the validation list). The final reference is still held by
> brw->batch.bo, as it was before.
>
> This removes the special case from a bunch of loops.
I left it around since the conditional atomic was a slight advantage.
But if it gets in the way of future cleanup,
Quoting Kenneth Graunke (2017-09-06 01:09:35)
> When a batch is flushed, INTEL_DEBUG=bat prints a message indicating
> which part of the code triggered the flushed, and some statistics about
> the batch/state buffer utilization.
>
> It also decodes the batchbuffer in debug builds...which is so muc
Quoting Kenneth Graunke (2017-09-06 01:09:39)
> Prior to the previous patch, we would pwrite the batchbuffer contents,
> and wanted to skip the execbuffer if that failed. Now, we write things
> directly to the map, so we don't need this check.
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c
Quoting Kenneth Graunke (2017-09-06 01:09:42)
> @@ -65,10 +74,8 @@ intel_batchbuffer_init(struct intel_screen *screen,
> struct brw_bufmgr *bufmgr = screen->bufmgr;
> const struct gen_device_info *devinfo = &screen->devinfo;
>
> - batch->reloc_count = 0;
> - batch->reloc_array_size =
which looks a lot like anv_reloc_list.
Simple translation,
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Quoting Kenneth Graunke (2017-09-06 01:09:45)
> Calling exit(1) when execbuffer fails is not necessarily safe.
> When running Piglit tests with a Mesa that submitted invalid commands
> to the GPU, I discovered the following problem:
>
> 1. do_flush_locked fails and calls exit(1)...invoking atexit
Quoting Kenneth Graunke (2017-09-06 01:09:46)
> However, this patch tries to retain the original flushing behavior - it
> adds the amount of batch and state space together, as if they were still
> co-existing in a single buffer. The hope is to flush at the same time
> as before. This is necessary
Quoting Kenneth Graunke (2017-09-06 01:09:47)
> Previously, we would just assert fail and die in this case. The only
> safeguard is the "estimated max prim size" checks when starting a draw
> (or compute dispatch or BLORP operation)...which are woefully broken.
>
> Growing is fairly straightforwa
Quoting Kenneth Graunke (2017-09-06 01:09:50)
> We now flush the batch when either the batchbuffer or statebuffer
> reaches the original intended batch size, instead of when the sum of
> the two reaches a certain size (which makes no sense now that they're
> separate buffers).
>
> With this change
Quoting Chris Wilson (2017-09-06 11:13:54)
> Quoting Kenneth Graunke (2017-09-06 01:09:50)
> > We now flush the batch when either the batchbuffer or statebuffer
> > reaches the original intended batch size, instead of when the sum of
> > the two reaches a certain size (whi
Quoting Kenneth Graunke (2017-09-06 01:09:35)
> When a batch is flushed, INTEL_DEBUG=bat prints a message indicating
> which part of the code triggered the flushed, and some statistics about
> the batch/state buffer utilization.
>
> It also decodes the batchbuffer in debug builds...which is so muc
Quoting Kenneth Graunke (2017-09-06 01:09:46)
> @@ -156,11 +158,14 @@ intel_batchbuffer_reset(struct intel_batchbuffer *batch,
> batch->map = brw_bo_map(NULL, batch->bo, MAP_READ | MAP_WRITE);
> batch->map_next = batch->map;
>
> + batch->state_bo = brw_bo_alloc(bufmgr, "statebuffer", ST
Quoting Kenneth Graunke (2017-09-06 01:09:50)
> We now flush the batch when either the batchbuffer or statebuffer
> reaches the original intended batch size, instead of when the sum of
> the two reaches a certain size (which makes no sense now that they're
> separate buffers).
>
> With this change
Quoting Chris Wilson (2017-09-06 10:45:57)
> Quoting Kenneth Graunke (2017-09-06 01:09:46)
> > However, this patch tries to retain the original flushing behavior - it
> > adds the amount of batch and state space together, as if they were still
> > co-existing in a single bu
Quoting Kenneth Graunke (2017-09-06 16:20:00)
> On Wednesday, September 6, 2017 3:08:44 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-06 01:09:47)
> > > Previously, we would just assert fail and die in this case. The only
> > > safeguard is the "
Quoting Kenneth Graunke (2017-09-06 16:33:48)
> On Wednesday, September 6, 2017 5:26:10 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-06 01:09:50)
> > > We now flush the batch when either the batchbuffer or statebuffer
> > > reaches the original inte
Quoting Kenneth Graunke (2017-09-08 08:19:03)
> On Wednesday, September 6, 2017 8:44:03 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-06 16:20:00)
> > > On Wednesday, September 6, 2017 3:08:44 AM PDT Chris Wilson wrote:
> > > > Quoting Kennet
Quoting Kenneth Graunke (2017-09-13 21:54:13)
> +/**
> + * Target sizes of the batch and state buffers. We create the initial
> + * buffers at these sizes, and flush when they're nearly full. If we
> + * underestimate how close we are to the end, and suddenly need more space
> + * in the middle o
Quoting Kenneth Graunke (2017-09-13 21:54:13)
> +/**
> + * Target sizes of the batch and state buffers. We create the initial
> + * buffers at these sizes, and flush when they're nearly full. If we
> + * underestimate how close we are to the end, and suddenly need more space
> + * in the middle o
Quoting Kenneth Graunke (2017-09-13 21:54:14)
> We need to set brw->no_batch_wrap to actually avoid flushing in the
> middle of our BLORP operation, and instead grow the batchbuffer.
> ---
> src/mesa/drivers/dri/i965/genX_blorp_exec.c | 16 ++--
> 1 file changed, 2 insertions(+), 14 de
Quoting Kenneth Graunke (2017-09-13 21:54:15)
> Now that we can grom the batchbuffer if we absolutely need the extra
s/grom/grow/
> space, we don't need to reserve space for the final do-or-die ending
> commands.
___
mesa-dev mailing list
mesa-dev@lists.
;t have to happen immediately.
Reviewed-by: Chris Wilson
P.S. Pretty please do make the reloc/execobject vectors a power of two :)
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Quoting Kenneth Graunke (2018-10-06 02:57:29)
> On Tuesday, October 2, 2018 11:06:23 AM PDT Chris Wilson wrote:
> > Reuse the same query object buffer for multiple queries within the same
> > batch.
> >
> > A task for the future is propagating the GL_NO_MEMORY err
The userspace driver does not exist in isolation and occasionally
depends on kernel uapi, and so it is useful in bug reports to include
that information. (radeonsi, r600 and radv already include utsname)
References: https://bugs.freedesktop.org/show_bug.cgi?id=108282
---
src/mesa/drivers/dri/comm
Quoting Ian Romanick (2018-10-10 00:24:00)
> On 10/09/2018 06:24 AM, Chris Wilson wrote:
> > The userspace driver does not exist in isolation and occasionally
> > depends on kernel uapi, and so it is useful in bug reports to include
> > that information. (radeonsi, r600 and
Quoting Kenneth Graunke (2018-10-19 18:51:36)
> Usually when making a new file, people copy some random other file
> to get the copyright header comments. Unfortunately, some of them
> are commented in a decades-old style, are word wrapped poorly, or
> worse, have a few subtle variations in the te
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to re
Quoting Rafael Antognolli (2018-10-29 17:19:53)
> +void
> +brw_enable_obj_preemption(struct brw_context *brw, bool enable)
> +{
> + const struct gen_device_info *devinfo = &brw->screen->devinfo;
> + assert(devinfo->gen >= 9);
> +
> + if (enable == brw->object_preemption)
> + return;
> +
Quoting Nanley Chery (2018-07-12 18:28:14)
> We'd like to reuse this helper.
>
> Cc:
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Quoting Nanley Chery (2018-07-12 18:28:16)
> Retile miptrees to a linear tiling less often. Retiling can cause issues
> with imported BOs.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106738
> Suggested-by: Chris Wilson
> Cc:
Reviewed-by: Ch
info, we see that non-linear tilings have
> widths greater than or equal to 128B.
Yup, we only have non-linear at this point and pitch has to a multiple
of tiles.
> Cc:
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.fre
Quoting aravindan.muthuku...@intel.com (2018-07-20 09:32:57)
> From: "Muthukumar, Aravindan"
>
> The Patch here is to give control to user/ application to really
> decide what's the max GPU load it would put. If that can be
> known in advance, rpcs can be programmed accordingly.
> This soluti
Quoting Nanley Chery (2018-07-23 18:17:15)
> Satisfy the BLT engine's row pitch limitation on the destination
> miptree. The destination miptree is untiled, so its row_pitch will be
> slightly less than or equal to the source miptree's row_pitch. Use the
> source miptree's row_pitch in can_blit_sli
Quoting Lionel Landwerlin (2018-07-24 13:34:57)
> That looks correct to me (and we do the same in Anv).
> Also a bit baffled that we haven't run into issues earlier :(
All the allocations should be in multiples of page size, alignment less
than a page size should be a no-op. Tracking down who does
Quoting Lionel Landwerlin (2018-07-24 13:45:18)
> On 24/07/18 13:42, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-07-24 13:34:57)
> >> That looks correct to me (and we do the same in Anv).
> >> Also a bit baffled that we haven't run into issues earlier :
Quoting Sergii Romantsov (2018-07-25 08:42:55)
> Hello,
> here is a backtrace:
...
Please try:
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e30ecc..8274c2e0b2f 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri
Quoting Sergii Romantsov (2018-07-25 10:37:29)
> Hello, Chris.
> Your variant also works.
> But i wonder about comment:
> /* If we don't have caching at this size, don't actually round the
> * allocation up.
> */
> if (bucket == NULL) {
>
> Has it any sense now? If 'no' - will delete
Quoting Lionel Landwerlin (2018-07-30 16:28:37)
> Gen10+ has an additional bit in MI_BATCH_BUFFER_END to signal the end
> of the context image.
Hmm, do you think we should perhaps include the BBE in the protocontext
we create in the kernel?
-Chris
___
me
Quoting Lionel Landwerlin (2018-07-30 17:08:47)
> On 30/07/18 16:45, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-07-30 16:28:37)
> >> Gen10+ has an additional bit in MI_BATCH_BUFFER_END to signal the end
> >> of the context image.
> > Hmm, do you think
allocations, while in the mean time making sure that
we do not waste any extra pages on them.
Signed-off-by: Chris Wilson
Cc: Sergii Romantsov
Cc: Lionel Landwerlin
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 24
1 file changed, 24 insertions
Quoting Michal Srb (2018-08-15 09:22:19)
> Hi,
>
> This is my first attempt to review patch for Mesa, so please take it with a
> grain of salt.
>
> On úterý 14. srpna 2018 20:21:40 CEST Chris Wilson wrote:
> > @@ -504,6 +506,24 @@ bo_alloc_internal(struct brw_bufmgr *b
Quoting Rafael Antognolli (2018-03-20 16:13:08)
> ring_name is " + " (e.g. rcs0). So we need to
> first compare the class name only, then get the instance id.
>
> Without this, INSTDONE is not being decoded.
>
> Signed-off-by: Rafael Antognolli
> Cc: Chris W
Quoting Lionel Landwerlin (2018-03-20 16:39:18)
> On 20/03/18 16:30, Chris Wilson wrote:
> > Quoting Rafael Antognolli (2018-03-20 16:13:08)
> >> ring_name is " + " (e.g. rcs0). So we need to
> >> first compare the class name only, then get the instance id.
&g
Quoting Scott D Phillips (2018-03-20 20:39:25)
> When building intel_tiled_memcpy for i686, the stack will only be
> 4-byte aligned. This isn't sufficient for SSE temporaries which
> require 16-byte alignment. Use the force_align_arg_pointer
> function attribute in that case to ensure sufficient a
Quoting Sergii Romantsov (2018-03-26 13:16:24)
> Negative deltas are used to fake a range in a large buffer.
> See 900a5c91eeb3
> "i965: Use negative relocation deltas to minimise vertex uploads"
>
> Gen8+ use 48-bit address relocations so need to extend the sign
Note that 48-bit relocations were
Quoting Sergii Romantsov (2018-03-26 14:11:26)
> Hello, Chris. Thank you for reviewing patch.
> Do you mean changing just only emit_reloc() parameter type or all the
> preceding
> callers too?
If you insist, but you don't have to. int32_t on the parameter is enough
to document and correct the typ
ty")
Signed-off-by: Chris Wilson
Cc: Rob Clark
Cc: Ben Widawsky
Cc: Emil Velikov
Cc: Eric Engestrom
Cc: Kenneth Graunke
Cc: Joonas Lahtinen
---
docs/relnotes/18.1.0.html| 1 +
include/EGL/eglext.h | 5 +
include/GL/internal/dri_interface.
901 - 1000 of 1057 matches
Mail list logo
