Re: [Mesa-dev] [PATCH] vma/tests: Fix compilation if limits.h defines PAGE_SIZE (v2)

Jon Turney writes: > per POSIX, limits.h may define PAGE_SIZE when the value is not indeterminate > > v2: just change the variable name, since there's no intended correlation > here between this value and the machine's actual page size. > > Cc: Scott D Phillips > Sign

Re: [Mesa-dev] [v4, 17/23] anv/allocator: Set the BO flags in bo_cache_alloc/import

Jason Ekstrand writes: > It's safer to set them there because we have the opportunity to properly > handle combining flags if a BO is imported more than once. Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedeskt

Re: [Mesa-dev] [v4, 18/23] anv/allocator: Support softpin in the BO cache

Jason Ekstrand writes: > --- > src/intel/vulkan/anv_allocator.c | 54 > +++- > 1 file changed, 53 insertions(+), 1 deletion(-) > > diff --git a/src/intel/vulkan/anv_allocator.c > b/src/intel/vulkan/anv_allocator.c > index 697da5f..f18e015 100644 > ---

Re: [Mesa-dev] [PATCH v4 22/23] anv: Soft-pin batch buffers

Jason Ekstrand writes: > From: Scott D Phillips > > Co-authored-by: Jason Ekstrand Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v4, 04/23] intel/common: Add an address de-cannonicalization helper

+gen_48b_address(uint64_t v) > +{ > + const int shift = 63 - 47; > + return (uint64_t)(v << shift) >> shift; The cast from uint64_t to uint64_t seems like a bit of unnecessary distraction, but it's like the other one so either way: Reviewed-by: Scott D Phillips > +} >

Re: [Mesa-dev] [v4,19/23] anv: Soft-pin client-allocated memory

Jason Ekstrand writes: > Now that we've done all that refactoring, addresses are now being > directly written into surface states by ISL and BLORP whenever a BO is > pinned so there's really nothing to do besides enable it. Reviewed-by: Scott D

Re: [Mesa-dev] [v4,10/23] anv: Use an anv_address in anv_buffer

Jason Ekstrand writes: Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 23/23] anv: Soft-pin everything else

Jason Ekstrand writes: > From: Scott D Phillips > > v2 (Jason Ekstrand): > - Break up Scott's mega-patch > > Reviewed-by: Jason Ekstrand Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.fre

Re: [Mesa-dev] [v4, 20/23] anv/batch_chain: Call batch_bo_finish at the end of end_batch_buffer

inish is called in a sensible > location. Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v4, 11/23] anv/cmd_buffer: Rework surface relocation helpers

e. Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v4, 07/23] anv: Use full anv_addresses in anv_surface_state

he addresses in the surface > state and doesn't really need the image view anymore. Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v4, 12/23] anv: Use an address for each anv_image plane

Jason Ekstrand writes: > This is better than having BO and offset fields. Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 05/23] anv: Add vma_heap allocators in anv_device

Jason Ekstrand writes: > From: Scott D Phillips > > These will be used to assign virtual addresses to soft pinned > buffers in a later patch. > > Two allocators are added for separate 'low' and 'high' virtual > memory areas. Another alternative would have been to add a >

Re: [Mesa-dev] [v4, 09/23] anv/cmd_buffer: Use anv_address for handling indirect parameters

Jason Ekstrand writes: Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v4, 08/23] anv: Use an anv_address in anv_buffer_view

Jason Ekstrand writes: > Instead of storing a BO and offset separately, use an anv_address. This > changes anv_fill_buffer_surface_state to use anv_address and we now call > anv_address_physical and pass that into ISL. Reviewed-by: Scott D

Re: [Mesa-dev] [v4,06/23] anv: Add some anv_address helpers

Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v4, 21/23] anv/batch_chain: Simplify secondary batch return chaining

om secondaries. The new helper doesn't > actually modify the batch in any way but instead just adjusts the > relocation as needed. Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 13/23] anv/blorp: Write relocated values into surface states

Jason Ekstrand writes: > From: Scott D Phillips > > v2 (Jason Ekstrand): > - Split the blorp bit into it's own patch and re-order a bit > - Use anv_address helpers > > Reviewed-by: Jason Ekstrand Reviewed-by: Scott D Phillips ___

Re: [Mesa-dev] [PATCH 1/8] util: Add a virtual memory allocator

Jason Ekstrand <ja...@jlekstrand.net> writes: > On Tue, May 8, 2018 at 10:58 AM, Jordan Justen <jordan.l.jus...@intel.com> > wrote: > >> On 2018-05-07 17:30:43, Scott D Phillips wrote: >> > From: Jason Ekstrand <jason.ekstr...@intel.com> >> >

Re: [Mesa-dev] [PATCH 10/10] i965: Require softpin support for Cannonlake and later.

ew features. I think the discussion about aliasing ppgtt won't impact this bit of code where we've already checked for gtt_size > 4 GiB. Maybe we should warn about aliasing ppgtt on newer gens? Either way, Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> > --- > src/mesa/drivers

Re: [Mesa-dev] [PATCH 09/10] i965: Softpin all buffers and never use relocations.

Good idea, thanks! Fixed for v2. I think the ALIASING_PPGTT test is actually redundant with the I915_CONTEXT_PARAM_GTT_SIZE > 4 GiB test that you're already doing. So patch v1 is Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> > --Ken > _

Re: [Mesa-dev] [PATCH 08/10] i965: Emit VF cache invalidates for 48-bit addressing bugs with softpin.

the bottom 32 bits of memory addresses. You mentioned it in the thread here, but I think it's important to mention in the comment too that the cache is considering the tuple of the bottom 32 bits and the vertex buffer's index in the state message. Otherwise it would look like an individual set of verti

Re: [Mesa-dev] [PATCH 07/10] i965: Prepare batchbuffer module for softpin support.

emory we're wasting due to overallocation, either here or by bucketing. I don't quite understand Chris's comment so this isn't meant to be an assertion that I think what he's saying isn't an issue, but fwiw: Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> ___

Re: [Mesa-dev] [PATCH 06/10] i965: Add virtual memory allocator infrastructure to brw_bufmgr.

mgr *bufmgr, > + enum brw_memory_zone memzone, > + uint64_t size, > + uint64_t alignment) > +{ > + uint64_t addr = __vma_alloc(bufmgr, memzone, size, alignment); > + > + /* Canonicalize the address. > +* > +* The Br

Re: [Mesa-dev] [PATCH 05/10] i965: Introduce a "memory zone" concept on BO allocation.

like ANY, where it allocates from either the high or low vma ranges. That's only relevant though because I apply a size restriction to the 'high' range. There's no such restriction here, so no need to have high allocations try the low range if they fail. Reviewed-by: Scott D Phillips <scott.d.phi

Re: [Mesa-dev] [PATCH 04/10] i965: Dump validation list on INTEL_DEBUG=bat, submit.

With submit, it's still easy to grep for > the older information, and the new information is nice too. Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> > --- > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++- > 1 file

Re: [Mesa-dev] [PATCH 03/10] util: Make vma.c support non-power-of-two alignments.

Kenneth Graunke <kenn...@whitecape.org> writes: > I want to use this in a bucketing allocator for i965. Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> > --- > src/util/vma.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/s

[Mesa-dev] [PATCH 1/8] util: Add a virtual memory allocator

ses so that the canonicalization code gets better testing. Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> Tested-by: Scott D Phillips <scott.d.phill...@intel.com> --- src/util/Makefile.sources | 4 +- src/util/meson.build | 2 + src/util/vma.

[Mesa-dev] [PATCH v2 4/8] anv: Add vma_heap allocators in anv_device

These will be used to assign virtual addresses to soft pinned buffers in a later patch. Two allocators are added for separate 'low' and 'high' virtual memory areas. Another alternative would have been to add a double-sided allocator, which wasn't done here just because it didn't appear to give

[Mesa-dev] [PATCH 8/8] anv: soft pin the remaining bos

--- src/intel/vulkan/anv_allocator.c | 16 +++- src/intel/vulkan/anv_batch_chain.c | 27 +-- src/intel/vulkan/anv_device.c | 32 src/intel/vulkan/anv_private.h | 16 src/intel/vulkan/anv_queue.c

[Mesa-dev] [PATCH v2 5/8] anv: soft pin state pools

The state_pools reserve virtual address space of the full BLOCK_POOL_MEMFD_SIZE, but maintain the current behavior of growing from the middle. v2: - rename block_pool::offset to block_pool::start_address (Jason) - assign state pool start_address statically (Jason) ---

[Mesa-dev] [PATCH v2 7/8] anv: elide relocations to pinned target bos

References to pinned bos won't need relocated, so just write the final value of the reference into the bo. Add a `set` to the relocation lists for tracking dependencies that were previously tracked by relocations. v2: - visit bos from the dependency set in a deterministic order (Jason) ---

[Mesa-dev] [PATCH 3/8] anv: move canonical_address calculation into a separate function

A later patch will make use of this in other places. Also, remove dependency on undefined behavior of left-shifting a signed value. --- src/intel/vulkan/anv_batch_chain.c | 12 +--- src/intel/vulkan/anv_private.h | 15 +++ 2 files changed, 16 insertions(+), 11 deletions(-)

[Mesa-dev] [PATCH v2 6/8] anv: use a separate pool for binding tables when soft pinning

Soft pinning lets us satisfy the binding table address requirements without using both sides of a growing state_pool. If you do use both sides of a state pool, then you need to read the state pool's center_bo_offset (with the device mutex held) to know the final offset of relocations that target

[Mesa-dev] [PATCH v2 2/8] util: Add a randomized test for the virtual memory allocator

The test pseudo-randomly makes allocations and deallocations with the virtual memory allocator and checks that the results are consistent. Specifically, we test that: * no result from the allocator overlaps an already allocated range * allocated memory fulfills the stated alignment requirement

[Mesa-dev] [PATCH v2 0/8] anv: softpin

Round two of anv softpin. The only notable feedback not incorporated in the series is Chris's suggestion about embedding the vma's allocation node in struct anv_bo; I'm leaving the allocator bit to Jason. Jason Ekstrand (1): util: Add a virtual memory allocator Scott D Phillips (7): util

Re: [Mesa-dev] [PATCH 8/9] anv: elide relocations to pinned target bos

Jason Ekstrand writes: > If I'm honest, I don't really like the way this patch worked out. It has > the virtue of being fairly simple and a nice incremental change. However, > it seems to me like we should be able to do better. That said, I don't > really know how

Re: [Mesa-dev] [PATCH 5/9] anv: Add vma_heap allocators in anv_device

Jason Ekstrand <ja...@jlekstrand.net> writes: > On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips <scott.d.phill...@intel.com >> wrote: > >> These will be used to assign virtual addresses to soft pinned >> buffers in a later patch. >> ---

Re: [Mesa-dev] [PATCH 1½/9] util: Add a randomized test for the virtual memory allocator

Scott D Phillips <scott.d.phill...@intel.com> writes: > The test pseudo-randomly makes allocations and deallocations with > the virtual memory allocator and checks that the results are > consistent. Specifically, we test that: > > * no result from the allocator overlaps

[Mesa-dev] [PATCH 1½/9] util: Add a randomized test for the virtual memory allocator

The test pseudo-randomly makes allocations and deallocations with the virtual memory allocator and checks that the results are consistent. Specifically, we test that: * no result from the allocator overlaps an already allocated range * allocated memory fulfills the stated alignment requirement

Re: [Mesa-dev] [PATCH 5/9] anv: Add vma_heap allocators in anv_device

Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Scott D Phillips (2018-05-02 17:01:05) >> +bool >> +anv_vma_alloc(struct anv_device *device, struct anv_bo *bo) >> +{ >> + if (!(bo->flags & EXEC_OBJECT_PINNED)) >> + return t

[Mesa-dev] [PATCH 2/9] util/set: add a set_clear function

Clear a set back to the state of having zero entries. --- src/util/set.c | 23 +++ src/util/set.h | 3 +++ 2 files changed, 26 insertions(+) diff --git a/src/util/set.c b/src/util/set.c index d71f771807f..2c9b09319ff 100644 --- a/src/util/set.c +++ b/src/util/set.c @@ -155,6

[Mesa-dev] [PATCH 7/9] anv: use a separate pool for binding tables when soft pinning

Soft pinning lets us satisfy the binding table address requirements without using both sides of a growing state_pool. If you do use both sides of a state pool, then you need to read the state pool's center_bo_offset (with the device mutex held) to know the final offset of relocations that target

[Mesa-dev] [PATCH 3/9] anv: remove unused field anv_queue::pool

The last use of the field was removed in 2015's ("48a87f4ba06 anv/queue: Get rid of the serial") --- src/intel/vulkan/anv_device.c | 1 - src/intel/vulkan/anv_private.h | 2 -- 2 files changed, 3 deletions(-) diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c index

[Mesa-dev] [PATCH 8/9] anv: elide relocations to pinned target bos

References to pinned bos won't need relocated, so just write the final value of the reference into the bo. Add a `set` to the relocation lists for tracking dependencies that were previously tracked by relocations. --- src/intel/vulkan/anv_batch_chain.c | 36

[Mesa-dev] [PATCH 9/9] anv: soft pin the remaining bos

--- src/intel/vulkan/anv_allocator.c | 16 +++- src/intel/vulkan/anv_batch_chain.c | 27 +-- src/intel/vulkan/anv_device.c | 32 src/intel/vulkan/anv_private.h | 16 src/intel/vulkan/anv_queue.c

[Mesa-dev] [PATCH 5/9] anv: Add vma_heap allocators in anv_device

These will be used to assign virtual addresses to soft pinned buffers in a later patch. --- src/intel/vulkan/anv_device.c | 75 ++ src/intel/vulkan/anv_private.h | 11 +++ 2 files changed, 86 insertions(+) diff --git a/src/intel/vulkan/anv_device.c

[Mesa-dev] [PATCH 6/9] anv: soft pin state pools

The state_pools reserve virtual address space of the full BLOCK_POOL_MEMFD_SIZE, but maintain the current behavior of growing from the middle. --- src/intel/vulkan/anv_allocator.c | 25 + src/intel/vulkan/anv_device.c| 13 + src/intel/vulkan/anv_private.h

[Mesa-dev] [PATCH 4/9] anv: move canonical_address calculation into a separate function

A later patch will make use of this in other places. Also, remove dependency on undefined behavior of left-shifting a signed value. --- src/intel/vulkan/anv_batch_chain.c | 12 +--- src/intel/vulkan/anv_private.h | 15 +++ 2 files changed, 16 insertions(+), 11 deletions(-)

[Mesa-dev] [PATCH 1/9] util: Add a virtual memory allocator

From: Jason Ekstrand This is simple linear-walk first-fit allocator roughly based on the allocator in the radeon winsys code. This allocator has two primary functional differences: 1) It cleanly returns 0 on allocation failure 2) It allocates addresses top-down

[Mesa-dev] [PATCH 0/9] anv: softpin

This series teaches anv how to pick its own virtual graphics addresses instead of using the relocation facility provided by the kernel. Jason Ekstrand (1): util: Add a virtual memory allocator Scott D Phillips (8): util/set: add a set_clear function anv: remove unused field anv_queue::pool

Re: [Mesa-dev] [PATCH 11/13] i965/miptree: Map with movntdqa for linear buffers only

Kenneth Graunke <kenn...@whitecape.org> writes: > On Monday, April 30, 2018 10:25:50 AM PDT Scott D Phillips wrote: >> Removes a place where gtt mapping is used. >> >> Reviewed-by: Nanley Chery <nanley.g.ch...@intel.com> >> Reviewed-by: Chris Wilson <ch.

Re: [Mesa-dev] [PATCH v2 00/13] 86 gtt maps

Kenneth Graunke <kenn...@whitecape.org> writes: > On Monday, April 30, 2018 10:25:39 AM PDT Scott D Phillips wrote: >> Here is a v2 of the 86 gtt maps series with the refactor >> suggestions by Chris folded in. >> >> Chris Wilson (8): >> i965: Move u

Re: [Mesa-dev] [PATCH 10/13] i965/miptree: Use cpu tiling/detiling when mapping

Kenneth Graunke <kenn...@whitecape.org> writes: > On Monday, April 30, 2018 10:25:49 AM PDT Scott D Phillips wrote: >> Rename the (un)map_gtt functions to (un)map_map (map by >> returning a map) and add new functions (un)map_tiled_memcpy that >> retur

Re: [Mesa-dev] [PATCH 09/13] i965/tiled_memcpy: inline movntdqa loads in tiled_to_linear

Matt Turner <matts...@gmail.com> writes: > On Mon, Apr 30, 2018 at 10:25 AM, Scott D Phillips > <scott.d.phill...@intel.com> wrote: >> The reference for MOVNTDQA says: >> >> For WC memory type, the nontemporal hint may be implemented by >&g

[Mesa-dev] [PATCH 12/13] i965/miptree: Split miptree_{, un}map logic and state management

o make recursive use of the map function without running afoul of the state management. Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 96 ++- 1 file changed, 64 insertions(+), 32 deletions(-) diff --gi

[Mesa-dev] [PATCH 08/13] i965/tiled_memcpy: ytiled_to_linear a cache line at a time

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 subsequent patch to obtain

[Mesa-dev] [PATCH 03/13] i965: Move unmap_movntdqa before map_movntdqa

From: Chris Wilson Reorder code to avoid a forward declaration in the next patch. Signed-off-by: Chris Wilson --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 24 1 file changed, 12 insertions(+), 12 deletions(-)

[Mesa-dev] [PATCH v2 00/13] 86 gtt maps

before map_etc i965: Move unmap_depthstencil before map_depthstencil i965: Record mipmap resolver for unmapping i965/miptree: Split miptree_{,un}map logic and state management Scott D Phillips (5): i965/tiled_memcpy: ytiled_to_linear a cache line at a time i965/tiled_memcpy: inline movntdqa

[Mesa-dev] [PATCH 10/13] i965/miptree: Use cpu tiling/detiling when mapping

Rename the (un)map_gtt functions to (un)map_map (map by returning a map) and add new functions (un)map_tiled_memcpy that return a shadow buffer 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

[Mesa-dev] [PATCH 06/13] i965: Move unmap_depthstencil before map_depthstencil

From: Chris Wilson Reorder code to avoid a forward declaration in the next patch. Signed-off-by: Chris Wilson --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 114 +- 1 file changed, 57 insertions(+), 57

[Mesa-dev] [PATCH 05/13] i965: Move unmap_etc before map_etc

From: Chris Wilson Reorder code to avoid a forward declaration in the next patch. Signed-off-by: Chris Wilson --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 42 +-- 1 file changed, 21 insertions(+), 21

[Mesa-dev] [PATCH 09/13] i965/tiled_memcpy: inline movntdqa loads in tiled_to_linear

The reference for MOVNTDQA says: For WC memory type, the nontemporal hint may be implemented by loading a temporary internal buffer with the equivalent of an aligned cache line without filling this data to the cache. [...] Subsequent MOVNTDQA reads to unread portions of the WC

[Mesa-dev] [PATCH 13/13] i965/miptree: recurse to miptree_map for depth in map_depthstencil

Call back to intel_miptree_map when mapping the separate depth miptree in map_depthstencil. This brings us back to the mapping method decision tree in miptree_map where we will then find the best mapping method for depth. --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 58

[Mesa-dev] [PATCH 01/13] i965: Move unmap_gtt before map_gtt

From: Chris Wilson Reorder code to avoid a forward declaration in the next patch. Signed-off-by: Chris Wilson Reviewed-by: Samuel Iglesias Gonsálvez --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 12 ++--

[Mesa-dev] [PATCH 07/13] i965: Record mipmap resolver for unmapping

he two if-chains become out of sync. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Kenneth Graunke <kenn...@whitecape.org> Cc: Scott D Phillips <scott.d.phill...@intel.com> Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> --- src/mesa/drivers/dri

[Mesa-dev] [PATCH 11/13] i965/miptree: Map with movntdqa for linear buffers only

Removes a place where gtt mapping is used. Reviewed-by: Nanley Chery Reviewed-by: Chris Wilson --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 02/13] i965: Move unmap_blit before map_blit

From: Chris Wilson Reorder code to avoid a forward declaration in the next patch. Signed-off-by: Chris Wilson --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 44 +-- 1 file changed, 22 insertions(+), 22

[Mesa-dev] [PATCH 04/13] i965: Move unmap_s8 before map_s8

From: Chris Wilson Reorder code to avoid a forward declaration in the next patch. Signed-off-by: Chris Wilson --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 60 +-- 1 file changed, 30 insertions(+), 30

Re: [Mesa-dev] [PATCH] meson: fix race condition revealed by using 0.44

Dylan Baker <dy...@pnwbakers.com> writes: > It turns out that the blocking target we had was hiding some race > conditions in the anv driver with anv_extensions.h generation, we should > fix those. > > CC: Scott D Phillips <scott.d.phill...@intel.com> > CC: Mark

Re: [Mesa-dev] [PATCH] anv/allocator: Don't srink either end of the block pool

tion here based on .end, the old size, seems like it would have to be wrong because we're trying to satisfy the post condition that there is enough room for .next on each side. So, Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> > } > > assert(center_b

[Mesa-dev] [PATCH v3 1/3] intel: fix check for 48b ppgtt support

The previous logic of the supports_48b_addresses wasn't actually checking if i915.ko was running with full_48bit_ppgtt. The ENOENT it was checking for was actually coming from the invalid context id provided in the test execbuffer. There is no path in the kernel driver where the presence of

Re: [Mesa-dev] [PATCH 7/7] i965: Record mipmap resolver for unmapping

Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Scott D Phillips (2018-04-12 15:17:16) >> Chris Wilson <ch...@chris-wilson.co.uk> writes: >> >> > When mapping a region of the mipmap_tree, record which complementary >> > method to use to

Re: [Mesa-dev] [PATCH] miptree-map

Chris Wilson writes: > Splitting intel_miptree_map() like so should help with the yuck factor. > Though don't we also need to treat the stencil_mt to a similar treatment > to avoid slow reads? I didn't do that because stencil_mt is W tiled and our tiling functions

Re: [Mesa-dev] [PATCH 7/7] i965: Record mipmap resolver for unmapping

can be introduced if the two if-chains become out of > sync. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Kenneth Graunke <kenn...@whitecape.org> > Cc: Scott D Phillips <scott.d.phill...@intel.com> for the series Review

[Mesa-dev] [RFC PATCH 5/5] i965/miptree: recurse to miptree_map for depth in map_depthstencil

Call back to intel_miptree_map when mapping the separate depth miptree in map_depthstencil. This brings us back to the mapping method decision tree in miptree_map where we hopefully find the most performant mapping method for depth. --- Here's an idea for a replacement of patch 5. Squirreling the

Re: [Mesa-dev] [PATCH v2 5/5] i965/miptree: Don't gtt map from map_depthstencil

Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Scott D Phillips (2018-04-03 21:05:45) >> Instead of gtt mapping, call out to other map functions (map_map >> or map_tiled_memcpy) for the depth surface. Removes a place where >> gtt mapping is used. >>

Re: [Mesa-dev] [PATCH v4 3/5] i965/miptree: Use cpu tiling/detiling when mapping

Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Scott D Phillips (2018-04-03 21:05:43) >> Rename the (un)map_gtt functions to (un)map_map (map by >> returning a map) and add new functions (un)map_tiled_memcpy that >> return a shadow buffer populated

Re: [Mesa-dev] [PATCH 2/5] i965/tiled_memcpy: inline movntdqa loads in tiled_to_linear

Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Chris Wilson (2018-04-05 20:54:54) > > Quoting Scott D Phillips (2018-04-03 21:05:42) [...] > > Ok, was hoping to see how you choose to use the streaming load, but I > > guess that's the next patch. > >

Re: [Mesa-dev] [PATCH] intel: aubinator: print out addresses of invalid instructions

%08x\n", p[0]); > + fprintf(ctx->fp, "%s0x%08"PRIx64": unknown instruction %08x%s\n", > + RED_COLOR, offset, p[0], reset_color); I guess the RED_COLOR here should conditionally be "" when !GEN_BATCH_DECODE_IN_COLOR, otherwise we'll pri

Re: [Mesa-dev] [PATCH] shader-db: Add hooks for open64 and fstat64 to intel_stub

Jason Ekstrand <ja...@jlekstrand.net> writes: > This gets the stub working again with meson builds of Mesa works, Reviewed-by: Scott D Phillips <scott.d.phill...@intel.com> > --- > intel_stub.c | 51 +++ > 1 fil

[Mesa-dev] [PATCH v2 5/5] i965/miptree: Don't gtt map from map_depthstencil

Instead of gtt mapping, call out to other map functions (map_map or map_tiled_memcpy) for the depth surface. Removes a place where gtt mapping is used. v2: add level, slice to debug print (Nanley) --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 52 --- 1 file changed,

[Mesa-dev] [PATCH 0/5] 86 gtt maps

Here is a resend of the series to remove gtt maps, with the addition of using MOVNTDQA when detiling which should help if we happen to detile from a WC map. Scott D Phillips (5): i965/tiled_memcpy: ytiled_to_linear a cache line at a time i965/tiled_memcpy: inline movntdqa loads

[Mesa-dev] [PATCH 2/5] i965/tiled_memcpy: inline movntdqa loads in tiled_to_linear

The reference for MOVNTDQA says: For WC memory type, the nontemporal hint may be implemented by loading a temporary internal buffer with the equivalent of an aligned cache line without filling this data to the cache. [...] Subsequent MOVNTDQA reads to unread portions of the WC

[Mesa-dev] [PATCH v4 3/5] i965/miptree: Use cpu tiling/detiling when mapping

Rename the (un)map_gtt functions to (un)map_map (map by returning a map) and add new functions (un)map_tiled_memcpy that return a shadow buffer 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

[Mesa-dev] [PATCH 4/5] i965/miptree: Map with movntdqa for linear buffers only

Removes a place where gtt mapping is used. Reviewed-by: Nanley Chery --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c

[Mesa-dev] [PATCH 1/5] i965/tiled_memcpy: ytiled_to_linear a cache line at a time

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 subsequent patch to obtain

Re: [Mesa-dev] [PATCH 5/5] i965/miptree: Don't gtt map from map_depthstencil

Nanley Chery <nanleych...@gmail.com> writes: > On Tue, Jan 09, 2018 at 11:17:02PM -0800, Scott D Phillips wrote: >> Instead of gtt mapping, call out to other map functions (map_map >> or map_tiled_memcpy) for the depth surface. Removes a place where >> gtt mapping is us

Re: [Mesa-dev] [PATCH 0/5] intel: error_decode improvements

> intel: genxml: add preemption control instructions > intel: error_decode: add an option to decode all buffers > intel: gen-decoder: don't decode fields beyond a dword length > intel: genxml: decode variable length MI_LRI > intel: gen-decoder: print all dword a field belo

Re: [Mesa-dev] [PATCH] i965/tiled_memcpy: realign rgba8_copy_aligned_dst stack in 32-bit builds

Chris Wilson <ch...@chris-wilson.co.uk> writes: > 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

[Mesa-dev] [PATCH] i965/tiled_memcpy: realign rgba8_copy_aligned_dst stack in 32-bit builds

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 alignment. ---

[Mesa-dev] [PATCH] anv: off-by-one in GetDescriptorSetLayoutSupport

Loop was accessing one more than bindingCount elements from pBindings, accessing uninitialized memory. Fixes: ddc4069122 ("anv: Implement VK_KHR_maintenance3") --- src/intel/vulkan/anv_descriptor_set.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH v3] i965/miptree: Use cpu tiling/detiling when mapping

Rename the (un)map_gtt functions to (un)map_map (map by returning a map) and add new functions (un)map_tiled_memcpy that return a shadow buffer 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

[Mesa-dev] [PATCH] intel/tools: aubinator: Catch gen11 "enhanced execlist" submission

Different registers are used for execlist submission in gen11, so also watch those. This code only watches element zero of the submit queue, which is all aubdump currently writes. --- src/intel/tools/aubinator.c | 26 -- 1 file changed, 20 insertions(+), 6 deletions(-)

Re: [Mesa-dev] [PATCH 2/5] i965/miptree: Use cpu tiling/detiling when mapping

Jason Ekstrand <ja...@jlekstrand.net> writes: > On Mon, Mar 5, 2018 at 11:39 AM, Nanley Chery <nanleych...@gmail.com> wrote: > >> On Tue, Jan 09, 2018 at 11:16:59PM -0800, Scott D Phillips wrote: >> > Rename the (un)map_gtt functions to (un)map_map (map by

Re: [Mesa-dev] [PATCH 4/4] i965/tiled_memcpy: Add support for Yf and Ys tiling/detiling

Ilia Mirkin <imir...@alum.mit.edu> writes: > On Feb 27, 2018 11:22 PM, "Scott D Phillips" <scott.d.phill...@intel.com> > wrote: > > > Yf and Ys are a family of tilings similar to Y. The actual address > > bit interleavings for Yf* and Ys* depend upon

[Mesa-dev] [PATCH 3/4] i965/tiled_memcpy: Add tile_addr_fn to compute the address of a tile

Replace the calculation of the individual tile address with a call through a function pointer to the calculation. This will be important with Ys tiling where a more complicated calculation is needed to derive the 4 kbyte sub-tile address. --- src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 29

[Mesa-dev] [PATCH 2/4] i965/tiled_memcpy: Pass cpp to tiling/untiling functions

As preparation for doing Yf/Ys tiling, pass the image's cpp into this tiling/untiling functions. The layout of Yf/Ys differ depending on cpp. Also plumb tiling and cpp through to the per-tile functions for ytile. --- src/mesa/drivers/dri/i965/intel_pixel_read.c | 1 +

[Mesa-dev] [PATCH 1/4] i965/tiled_memcpy: ytiled_to_linear a cache line at a time

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 subsequent patch to obtain

[Mesa-dev] [PATCH 4/4] i965/tiled_memcpy: Add support for Yf and Ys tiling/detiling

Yf and Ys are a family of tilings similar to Y. The actual address bit interleavings for Yf* and Ys* depend upon the bits-per-pixel value of the surface, where 128-, 32-, and 8-bpp tiles are square and 64- and 16-bpp tiles have a 2:1 aspect ratio. The address bit layout of Yf and Ys are the same

  1   2   >