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
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.free
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
> --- a/src/
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
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-b
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
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@list
_finish 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
+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
> +}
esses 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
nymore.
Reviewed-by: Scott D Phillips
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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 ha
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
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
Reviewed-by: Scott D Phillips
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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
__
Jason Ekstrand writes:
> On Tue, May 8, 2018 at 10:58 AM, Jordan Justen
> wrote:
>
>> On 2018-05-07 17:30:43, Scott D Phillips wrote:
>> > From: Jason Ekstrand
>> >
>> > This is simple linear-walk first-fit allocator roughly based on 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
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.c | 4
> 1 fil
ks! 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
> --Ken
> ___
> mesa-dev mailing list
>
r 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 individu
ry 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
*/
> +static uint64_t
> +vma_alloc(struct brw_bufmgr *bufmgr,
> + enum brw_memory_zone memzone,
> + uint64_t size,
> + uint64_t alignment)
> +{
> + uint64_t addr = __vma_alloc(bufmgr, memzone, size, alig
locates 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
> ---
>
27;s still easy to grep for
> the older information, and the new information is nice too.
Reviewed-by: Scott D Phillips
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Kenneth Graunke writes:
> I want to use this in a bucketing allocator for i965.
Reviewed-by: Scott D Phillips
> ---
> src/util/vma.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/util/vma.c b/src/util/vma.c
> index 3d61f6969e
etter testing.
Reviewed-by: Scott D Phillips
Tested-by: Scott D Phillips
---
src/util/Makefile.sources | 4 +-
src/util/meson.build | 2 +
src/util/vma.c| 231 ++
src/util/vma.h| 53 +++
4 files changed, 289 inser
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 any
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)
---
src/intel/vulkan/anv_all
---
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
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)
---
src/in
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 t
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
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 Phill
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(-)
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 off-hand and this looks corre
Jason Ekstrand writes:
> On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips > wrote:
>
>> These will be used to assign virtual addresses to soft pinned
>> buffers in a later patch.
>> ---
>> src/intel/vulkan/anv_device.c | 75 ++
>
Scott D Phillips 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 an already allocated range
>
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
Chris Wilson 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 true;
>> +
>> + pthread_mutex_
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
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 t
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 856035
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
sr
---
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
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 b/s
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
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(-)
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 instead of bottom-up.
The sec
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
Kenneth Graunke 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
>> Reviewed-by: Chris Wilson
>> ---
>> src/mesa/drivers/dri/i965/intel_mipm
Kenneth Graunke 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 unmap_gtt before map_gtt
>>
Kenneth Graunke 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
>> return a shadow buffer populated with the intel_tile
Matt Turner writes:
> On Mon, Apr 30, 2018 at 10:25 AM, Scott D Phillips
> wrote:
>> 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
>
function without running afoul of the state
management.
Reviewed-by: Scott D Phillips
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 96 ++-
1 file changed, 64 insertions(+), 32 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers
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
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(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_
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
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 those
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 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipm
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 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipm
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
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 -
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 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/driv
sync.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Scott D Phillips
Reviewed-by: Scott D Phillips
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 33 +--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 6 +
2 files changed, 22 insertions(+), 17 deletions
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 a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel
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 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipm
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 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipm
Dylan Baker 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
> CC: Mark Janes
> Fixes: 92550d9b16d2b295bdac087f31b1fd6d0f808e02
>
on 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
> }
>
> assert(center_bo_offset % PAGE_SIZE == 0);
> --
&g
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
EXEC_O
Chris Wilson writes:
> Quoting Scott D Phillips (2018-04-12 15:17:16)
>> Chris Wilson writes:
>>
>> > When mapping a region of the mipmap_tree, record which complementary
>> > method to use to unmap it afterwards. By doing so we can avoid
>> > dupli
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
don't handle that. At the momen
hains become out of
> sync.
>
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
> Cc: Scott D Phillips
for the series
Reviewed-by: Scott D Phillips
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
d
Chris Wilson 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.
>>
>> v2: add le
Chris Wilson 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 with the intel_tiled_memcpy
>&g
Chris Wilson 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.
> >
> > Reviewed-by
RIx64": 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 print red and never stop.
With that,
Reviewed-by:
Jason Ekstrand writes:
> This gets the stub working again with meson builds of Mesa
works,
Reviewed-by: Scott D Phillips
> ---
> intel_stub.c | 51 +++
> 1 file changed, 51 insertions(+)
>
> diff --git a/intel_stub.c b/in
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,
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 in
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
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 those
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
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 58ffe
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
Nanley Chery 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 used.
>> ---
>
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 belongs to
Series is
Reviewed-by: Scott
Chris Wilson 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 the force_align_arg_pointe
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.
---
src/mesa/drivers/dri/i965/intel_tiled_me
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 a/src/intel/vulkan/anv_descri
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 those
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(-)
dif
Jason Ekstrand writes:
> On Mon, Mar 5, 2018 at 11:39 AM, Nanley Chery 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
>> > returning a map) and add new functions (un)map_t
Ilia Mirkin writes:
> On Feb 27, 2018 11:22 PM, "Scott D Phillips"
> wrote:
>
> > 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
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 +++
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 +
src/mesa/drivers/dri/i965
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
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 i
1 - 100 of 176 matches
Mail list logo
