Dylan Baker writes:
> Quoting Jakob Bornecrantz (2017-10-14 13:03:14)
> > On Sat, Oct 14, 2017 at 1:36 AM, Dylan Baker wrote:
> > > I'm not sure about this approach, we would need a way to add
> > > depends to meson,
'add depends' meaning having a way for the build steps themselves to
depend on
Dylan Baker writes:
> Quoting Scott D Phillips (2017-10-16 10:04:45)
> > Dylan Baker writes:
> >
> > > Quoting Jakob Bornecrantz (2017-10-14 13:03:14)
> > > > On Sat, Oct 14, 2017 at 1:36 AM, Dylan Baker
> > > > wrote:
> > > > &g
Matt Turner writes:
> Reviewed-by: Scott D Phillips
> ---
> src/intel/compiler/brw_inst.h | 108
> ++
> 1 file changed, 108 insertions(+)
>
> diff --git a/src/intel/compiler/brw_inst.h b/src/intel/compiler/brw_inst.h
> inde
swizzle);
> + brw_inst_set_3src_a16_src0_subreg_nr(devinfo, inst,
> get_3src_subreg_nr(src0));
> + brw_inst_set_3src_src0_reg_nr(devinfo, inst, src0.nr);
> + brw_inst_set_3src_src0_abs(devinfo, inst, src0.abs);
> + brw_inst_set_3src_src0_negat
Lionel Landwerlin writes:
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/common/gen_decoder.c | 59
> ++
> 1 file changed, 37 insertions(+), 22 deletions(-)
>
> diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
> index a6
Lionel Landwerlin writes:
> This is required to have output redirected to something else than a
> file descriptor (stdout).
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/compiler/brw_compile_clip.c | 5 +-
> src/intel/compiler/brw_compile_sf.c | 5 +-
> src/intel/compiler
Lionel Landwerlin writes:
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/tools/aubinator.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index 48d4456cc16..2c4eaab1701 100644
> --- a/src/intel/to
print the value of idx_program so the order
programs were found can be reversed.
Patches 1-15 are
Reviewed-by: Scott D Phillips
> ---
> src/intel/tools/aubinator_error_decode.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/src/intel
Lionel Landwerlin writes:
Is this one a rebase error? The commit message doesn't make sense with
the patch, and the change from Patch 22 gets reverted here.
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/common/gen_decoder.c | 8
> src/intel/common/gen_decoder.h | 3 ++-
> 2 fil
er you feel about that, modulo comments made,
Patches 16-25 are:
Reviewed-by: Scott D Phillips
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/compiler/brw_compile_clip.c | 5 +-
> src/intel/compiler/brw_compile_sf.c | 5 +-
> src/intel/compiler/brw_dis
Lionel Landwerlin writes:
> We want to introduce a reader interface for accessing memory, so that
> later on we can use different ways of storing the content of the GTT
> address space that don't involve a pointer to a linear buffer.
I'm kinda sceptical that this is the best way to achieve what
Lionel Landwerlin writes:
The new names make sense to me, but the old names are what are in the
prm. I'm not sure what consistency we prefer to prioritize, so I'll have
to defer to someone else to review Patches 27 and 28
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/genxml/gen10.xml
Lionel Landwerlin writes:
> On 31/10/17 20:54, Scott D Phillips wrote:
>> Lionel Landwerlin writes:
>>
>>> We want to introduce a reader interface for accessing memory, so that
>>> later on we can use different ways of storing the content of the GTT
>&
Lionel Landwerlin writes:
> On 31/10/17 23:04, Scott D Phillips wrote:
>> Lionel Landwerlin writes:
>>
>>> On 31/10/17 20:54, Scott D Phillips wrote:
>>>> Lionel Landwerlin writes:
>>>>
>>>>> We want to introduce a reader in
Lionel Landwerlin writes:
> On 31/10/17 21:11, Scott D Phillips wrote:
>>> +}
>> [snip imgui]
>>
>> imgui seems to be the first instance of someone pasting a sizeable third
>> party library into the repo. I'm not sure how everyone feels about
>>
Dylan Baker writes:
> Quoting Lionel Landwerlin (2017-11-01 14:25:03)
>> On 01/11/17 20:30, Dylan Baker wrote:
>> > Quoting Scott D Phillips (2017-11-01 10:30:09)
>> >> Lionel Landwerlin writes:
>> >>
>> >>> On 31/10/17 21:11
KhronosGroup/OpenGL-Registry/pull/76
https://github.com/KhronosGroup/OpenGL-Registry/issues/77
> Cheers,
> Eric
>
> [1] https://gitlab.khronos.org/opengl/API/issues/new
> [2] https://github.com/KhronosGroup/OpenGL-Registry/issues/new
>
>>
>> On 06/30/2017 01:49
BLEND_STATE packing was modified to be variable-length in:
9670124e31 genxml: Make BLEND_STATE command support variable length array.
The initial gen10.xml still had the old, fixed-length style
definition for BLEND_STATE. So gen10_upload_blend_state would
overwrite the packed BLEND_STATE_ENTRYs
Matt Turner writes:
> ---
> src/intel/compiler/brw_reg_type.c | 65
> +--
> 1 file changed, 29 insertions(+), 36 deletions(-)
>
> diff --git a/src/intel/compiler/brw_reg_type.c
> b/src/intel/compiler/brw_reg_type.c
> index 8aac0ca009..b0696570e5 100644
> ---
l/compiler/brw_reg.h
> +++ b/src/intel/compiler/brw_reg.h
> @@ -203,29 +203,25 @@ brw_mask_for_swizzle(unsigned swz)
> }
>
> enum PACKED brw_reg_type {
And maybe add a comment here like this part of the commit message:
* The ordering has been chosen so that no enum value is t
Matt Turner writes:
> The hardware encodings often mean different things depending on whether
> the source is an immediate.
> ---
> src/intel/compiler/brw_disasm.c | 46 ---
> src/intel/compiler/brw_eu_compact.c | 8 +--
> src/intel/compiler/brw_eu_defines.h | 48 +
Matt Turner writes:
> The mixture of hardware encodings and logical types has caused lots of
> confusion. It's time to fix that.
fwiw, apart from the one comment about sizeof V/UV, series is
Reviewed-by: Scott D Phillips
> ___
>
Matt Turner writes:
> On Tue, Aug 8, 2017 at 4:25 PM, Scott D Phillips
> wrote:
>>> + [BRW_HW_IMM_TYPE_UV] = 2,
>>> + [BRW_HW_IMM_TYPE_VF] = 4,
>>> + [BRW_HW_IMM_TYPE_V] = 2,
>>
>> Is this right? I see it was there before,
intel_miptree_texture_aux_usage() takes an isl_format, but we are
passing a mesa_format. clang warns:
brw_blorp.c:305:52: warning: implicit conversion from enumeration
type 'mesa_format' to different enumeration type
'enum isl_format' [-Wenum-conversion]
intel_miptree_texture_aux_u
on that a Fixes tag somehow magically got
it to the right stable branches. If that's not the case then it
looks like it should be:
Cc: "17.2"
> --Jason
>
> On Wed, Aug 9, 2017 at 3:52 PM, Scott D Phillips > wrote:
>
>> intel_miptree_texture_aux_usage() takes
Tapani Pälli writes:
> Hello;
>
> On 07/25/2017 05:17 PM, Marathe, Yogesh wrote:
>> Hi Matt, Sorry for late reply, please see below.
>>
>>> -Original Message-
>>> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
>>> Of Matt Turner
>>> Sent: Saturday, July 22, 2017
On gen >= 9, minmax reduction modes are available as a flag in
SAMPLER_STATE.
---
docs/features.txt | 2 +-
src/mesa/drivers/dri/i965/brw_formatquery.c | 4
src/mesa/drivers/dri/i965/genX_state_upload.c | 10 ++
src/mesa/drivers/dri/i965/intel_extension
This extension provides a new texture and sampler parameter
(TEXTURE_REDUCTION_MODE_ARB) which allows applications to produce
a filtered texel value by computing a component-wise minimum (MIN)
or maximum (MAX) of the texels that would normally be averaged.
---
CTS tests KHR-GL45.texture_filter_minm
Ian Romanick writes:
> On 11/19/2017 01:31 AM, Kenneth Graunke wrote:
>> On Thursday, November 16, 2017 11:50:48 AM PST Ian Romanick wrote:
>>> On 11/14/2017 02:54 PM, Scott D Phillips wrote:
>>>> On gen >= 9, minmax reduction modes are availabl
Jordan Justen writes:
> This will dump the INTERFACE_DESCRIPTOR_DATA along with the associated
> samplers & surfaces.
>
> Signed-off-by: Jordan Justen
Reviewed-by: Scott D Phillips
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 24
This extension provides a new texture and sampler parameter
(TEXTURE_REDUCTION_MODE_ARB) which allows applications to produce
a filtered texel value by computing a component-wise minimum (MIN)
or maximum (MAX) of the texels that would normally be averaged.
v2: - Remove extension from compat contex
Memtrace aubs are similar to classic aubs, with the major
difference being how command submission is serialized (as register
writes instead of a high-level submit message). Some internal
tools generate or consume only memtrace aubs.
---
src/intel/tools/aubinator.c | 117 +++
---
src/intel/tools/aubinator.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 48d4456cc1..f1ad3a948b 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -837,6 +837,8 @@ handle_tra
A later patch will use the aubinator_init() function from the
memtrace aub header handler.
---
src/intel/tools/aubinator.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index f
GLES/gl.h has historically provided some typedefs that are not
used in the API itself. Restore these typedefs that were lost to
avoid breaking applications.
These seem to be the only typedefs removed in the update.
Fixes: 7fd0817 "Update Khronos-supplied headers"
---
include/GLES/gl.h| 6 ++
New generated files from:
bb1e6ff161c ("spirv: Add a prepass to set types on vtn_values")
65fc16c9741 ("autotools: set XA versions in configure.ac and configure header
file")
---
src/compiler/spirv/.gitignore| 1 +
src/gallium/state_trackers/xa/.gitignore | 1 +
2 files changed,
Matt Turner writes:
> Some cases weren't handled, such as stride 4 which is needed for 64-bit
> operations. Presumably fixes the assertion failure mentioned in commit
> 2d0457203871 (Revert "i965/fs: Use align1 mode on ternary instructions
> on Gen10+") but who can really say since the commit neg
Matt Turner writes:
> This reverts commit 2d0457203871c843ebfc90fb895b65a9b14cd9bb.
Reviewed-by: Scott D Phillips
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Matt Turner writes:
> On Mon, Jan 8, 2018 at 5:01 PM, Scott D Phillips
> wrote:
>> Matt Turner writes:
>>
>>> Some cases weren't handled, such as stride 4 which is needed for 64-bit
>>> operations. Presumably fixes the assertion failure mentioned in
When initializing mcs, map with MAP_RAW and fill in the linear
map. Removes a place where gtt mapping is used.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri
Removes a place where gtt mapping is used.
---
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 e4a3f163d2..fa4ae06399 100644
---
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.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95 ---
1 file changed, 86 in
In all current uses, the linear surface is only allocated starting
at (xt1, yt1) anyway, so this improves the calling ergonomics.
---
src/mesa/drivers/dri/i965/intel_pixel_read.c | 2 +-
src/mesa/drivers/dri/i965/intel_tex_image.c| 4 ++--
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 1
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.
---
This is a bit icky, perhaps something like mapping z_mt with
BRW_MAP_DIRECT_BIT could be cleaner (but in that case the
depthstencil mapping and
eturn reg.subnr / 4;
}
Does the code above need updated for DF registers too? Or is that
already accounted for somehow?
I'm probably just missing something. With an explanation Patches 1-3 are:
Reviewed-by: Scott D Phillips
> ---
> src/intel/compiler/brw_disasm.c | 31 +++
Matt Turner writes:
> ---
> src/intel/compiler/brw_disasm.c | 12 ---
> src/intel/compiler/brw_inst.h | 4 +--
> src/intel/compiler/brw_reg_type.c | 76
> ---
> src/intel/compiler/brw_reg_type.h | 7 ++--
> 4 files changed, 79 insertions(+), 20 de
brw_inst *inst, enum brw_reg_type type)
> \
> +{
> \
> + enum gen10_align1_3src_exec_type exec_type =
> \
> + (en
Matt Turner writes:
> ---
> src/intel/compiler/brw_disasm.c | 399
> +---
> src/intel/compiler/brw_eu_defines.h | 11 -
> 2 files changed, 322 insertions(+), 88 deletions(-)
>
> diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c
>
Matt Turner writes:
> ---
> src/intel/compiler/brw_eu_emit.c | 196
> ---
> 1 file changed, 143 insertions(+), 53 deletions(-)
>
> diff --git a/src/intel/compiler/brw_eu_emit.c
> b/src/intel/compiler/brw_eu_emit.c
> index f1a2283de8..7f3980f83e 100644
> ---
Matt Turner writes:
> Align1 mode offers some nice features over align16, like access to more
> data types and the ability to use a 16-bit immediate. This patch does
> not start using any new features. It just emits ternary instructions in
> align1 mode.
> ---
> src/intel/compiler/brw_fs_generat
Matt Turner writes:
> The documentation says it applies only to Gens 8 and 9.
Patch 10 & 13:
Reviewed-by: Scott D Phillips
> ---
> src/intel/compiler/brw_fs_generator.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/intel/compiler/brw_fs_generator.cpp
---
Caveat: meson won't pick up modifications to the Makefile.sources
files without something like:
https://github.com/mesonbuild/meson/pull/2490
bin/get-makefile-sources-vars.py | 50 +++
meson.build | 85
2 files
---
src/mesa/drivers/dri/i965/meson.build | 114 +-
1 file changed, 1 insertion(+), 113 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/meson.build
b/src/mesa/drivers/dri/i965/meson.build
index 144a254bd6..0101c8b91b 100644
--- a/src/mesa/drivers/dri/i965/meso
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:
> 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
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:
> 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
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
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
nymore.
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
> +}
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
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
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
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
>
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
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
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
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 -
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
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
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
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
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
>
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
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
>>
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
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
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
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
---
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
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
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
1 - 100 of 176 matches
Mail list logo
