Quoting Kenneth Graunke (2017-07-07 07:08:16)
> On Thursday, July 6, 2017 10:51:49 PM PDT Kenneth Graunke wrote:
> > On Wednesday, July 5, 2017 2:24:55 PM PDT Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2017-07-05 21:56:54)
> > > > ---
> > > > s
ioctl. Historically libdrm used set-domain as we did not
have an explicit wait-ioctl (and the patches to teach it to use wait if
available were lost in the mists). Since mesa already depends upon a
kernel support the wait-ioctl, we do not need to supply a fallback.
Signed-off-by: Chris Wilson
Cc: D
before as is currently the case.
v2: fixup assert to use GL_SYNC_GPU_COMMANDS_COMPLETE (Chad)
Reported-by: Sergi Granell
Fixes: c636284ee8ee ("i965/sync: Implement DRI2_Fence extension")
Signed-off-by: Chris Wilson
Cc: Sergi Granell
Cc: Rob Clark
Cc: Chad Versace
Cc: Daniel Stone
Cc: Ke
Quoting Ben Widawsky (2017-07-07 19:42:25)
> On 17-07-07 11:34:48, Chris Wilson wrote:
> >Quoting Ben Widawsky (2017-07-07 00:27:01)
> >> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> >> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> >> drivers/gpu/drm/i915/i915_pc
out. That was until I saw what you were planning to do for anv. Hmm,
that puts the oldest kernel that might support anv as
commit 51bc140431e233284660b1d22c47dec9ecdb521e [v4.3]
Author: Chris Wilson
Date: Mon Aug 31 15:10:39 2015 +0100
drm/i915: Always mark the object as dirty when used by
Valgrind doesn't actually implement VALGRIND_FREELIKE_BLOCK as the
exact inverse of VALGRIND_MALLOCLIKE_BLOCK. It makes the block
inaccessible, but still leaves it defined in its allocation tracker i.e.
it will report the mmap as lost despite the call to FREELIKE!
Instead of treating the mmap as a
Not all objects will be mappable for direct access by the CPU (either
using WC/CPU or WC paths), for example, a dmabuf wrapping an object on a
foreign device or an object wrapping access to stolen memory. Since
either the physical pages are not known or even do not exist, we need to
use the mediate
patch.
My apologies for not noticing! I appear to have fixed it in a rebase and
so it disappeared from my tree.
Reviewed-by: Chris Wilson
Doing a quick grep on the remaining bufmgr->lock shows that we are now
only locking around the global hash tables.
-Chris
Quoting Kenneth Graunke (2017-07-12 08:22:24)
> From: Matt Turner
>
> Write-combine mappings give much better performance on writes than
> uncached access through the GTT.
>
> Improves performance of GFXBench 4's gl_driver2 benchmark at 1024x768
> on Apollolake by 3.6086% +/- 0.674193% (n=15).
>
Quoting Kenneth Graunke (2017-07-12 08:22:25)
> The non-LLC story was a horror show. We uploaded data via pwrite
> (drm_intel_bo_subdata), which would stall if the cache BO was in
> use (being read) by the GPU. Obviously, we wanted to avoid that.
> So, we tried to detect whether the buffer was bu
Quoting Chris Wilson (2017-07-12 10:40:43)
> Quoting Kenneth Graunke (2017-07-12 08:22:25)
> > The non-LLC story was a horror show. We uploaded data via pwrite
> > (drm_intel_bo_subdata), which would stall if the cache BO was in
> > use (being read) by the GPU. Obviously, we
Quoting Wu, Zhongmin (2017-07-13 09:31:15)
> As for the using of last fence when the batch buffer is empty for
> create_fence_fd, I suggest it can be another story and we will try to
> optimize it in the future...
Note that is a backend problem. If you call a driver interface to create
a fence
Quoting kevin.rogo...@intel.com (2017-12-13 10:18:38)
> From: Kevin Rogovin
>
> v2:
> Comments indicating that brw_bo_padding_is_good() will do the required
> waiting for GPU commands to finish
>
> Signed-off-by: Kevin Rogovin
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 19 ++
Quoting Rogovin, Kevin (2017-12-13 11:19:10)
> Hi,
>
> > Actually that's not strictly true. Since you only do a pread here, it will
> > only synchronize against the last declared write to the bo.
> > There's no guaranteed sync with the last batch for a set of read-only bo.
> > Similarly, because
Quoting Rogovin, Kevin (2017-12-13 11:59:41)
> Just to make sure of the reason of the original objection to trusting pread
> blindly:
> pread will miss writes IF the GEM BO was not listed in the execbuffer2 ioctl.
Yes. It's just the accidental writes into the read-only bo that you may
miss. You
require robust segregation (e.g.
ARB_robustness).
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 23 +--
src/mesa/drivers/dri/i965/brw_bufmgr.h | 2 +-
src/mesa/drivers/dri/i965/brw_context.c | 2 +-
3 files changed, 19 insertions(+), 8 deletions
Always enable use of HW logical contexts to preserve GPU state between
batches when the kernel supports such constructs, continuing to enforce
the required support for gen6+.
At runtime, this effectively removes the BRW_NEW_CONTEXT flag (and the
upload of invariant state) from the start of every b
Quoting Jason Ekstrand (2017-12-15 15:40:51)
> What does this actually gain us? Multiple contexts aren't common.
UE4 is one that I know of that uses multiple contexts to separate
rendering from presentation, afaik. The API is precursor to try and
define a lighterweight context object for future e
Quoting Jason Ekstrand (2017-12-15 16:21:42)
> On Fri, Dec 15, 2017 at 5:42 AM, Chris Wilson
> wrote:
>
> Every client (everyone instance that opens /dev/dri/card0 or the render
> nodes), receives a unique per-process GTT (where supported by the
> hardware, unfort
Quoting Jason Ekstrand (2017-12-15 17:38:10)
> On Fri, Dec 15, 2017 at 8:27 AM, Chris Wilson
> wrote:
>
> Quoting Jason Ekstrand (2017-12-15 16:21:42)
> > On Fri, Dec 15, 2017 at 5:42 AM, Chris Wilson
> wrote:
> >
> > Every client (ever
Quoting Kenneth Graunke (2018-01-05 18:56:32)
> Growing the batch/state buffer is a lot more dangerous than I thought.
>
> A number of places emit multiple state buffer sections, and then write
> data to the returned pointer, or save a pointer to brw->batch.state.bo
> and then use it in relocation
return false;
> + }
> + expected_value = next_noise_value(expected_value);
> + }
> + drm_munmap(mapped, bo->padding_size);
> + }
> + return true;
> +}
Looks good from the uabi pov and interaction with brw_bo.
Reviewed-by: Chris Wilson
I'
Quoting Jason Ekstrand (2018-01-12 01:40:52)
> This helper should be used carefully as setting tiling is a racy
> operation since it potentially interacts with other processes. Still,
> it is a useful thing to be able to do.
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/drivers/dri/
course means we need to teach aubinator_error_decode how
to map both sets of ring names onto its register maps.
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Kenneth Graunke
---
src/intel/tools/aubinator_error_decode.c | 122
Quoting Michel Thierry (2018-01-18 16:44:18)
> On 1/17/2018 7:47 AM, Chris Wilson wrote:
> > The kernel is moving to a $class$instance naming scheme in preparation
> > for accommodating more rings in the future in a consistent manner. It is
> > already using the naming schem
r BO - and
> we'll sort it out and combine the two properly in the end.
>
> v2/v3:
> - Handle stale pointers in the shadow copy case, where realloc may or
> may not move our shadow copy to a new address.
> - Track the partial map explicitly, to avoid problems with buffer r
Quoting Tapani Pälli (2018-01-19 10:44:49)
> diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
> index 34c0989108..46069dcdc7 100644
> --- a/src/intel/vulkan/anv_gem.c
> +++ b/src/intel/vulkan/anv_gem.c
> @@ -302,6 +302,55 @@ close_and_return:
> return swizzled;
> }
>
> +s
Quoting Samuel Iglesias Gonsálvez (2018-01-19 11:58:24)
> Reviewed-by: Samuel Iglesias Gonsálvez
Me too!
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
h to the kernel").
Fixes: 6d87500fe12e ("dri: Change __DriverApiRec::CreateContext to take a
struct for attribs")
Signed-off-by: Chris Wilson
Cc: Adam Jackson
Cc: Nicolai Hähnle
Cc: Emil Velikov
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 4 +++-
1 fi
Quoting Kenneth Graunke (2017-09-16 09:31:26)
> We'll want to pass this to brw_bo_map in a moment.
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
curiosity, the GTT mmap also failed? If you didn't have enough
virtual space for one mmap, the other should also fail.
Reviewed-by: Chris Wilson
How important is the requirement to flag GL_NO_MEMORY rather than
explode? Even for batch reset, we should still be able to propagate the
error
Quoting Kenneth Graunke (2017-09-17 15:06:49)
> On Sunday, September 17, 2017 1:58:16 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-16 09:31:27)
> > > This shouldn't really happen in practice, but I hit it a couple of times
> > > when running a dr
Quoting Kenneth Graunke (2017-09-18 18:56:56)
> This is, by definition, finishing the batch.
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/dr
Quoting Kenneth Graunke (2017-09-18 18:56:57)
> brw_finish_batch emits commands needed at the end of every batch buffer,
> including any workarounds. In the past, we freed up some "reserved"
> batch space before calling it, so we would never have to flush during
> it. This was error prone and eas
Quoting Kenneth Graunke (2017-09-18 21:44:57)
> On Monday, September 18, 2017 11:14:35 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-18 18:56:57)
> > > brw_finish_batch emits commands needed at the end of every batch buffer,
> > > including any workarou
Quoting Kenneth Graunke (2017-09-18 21:38:09)
> On Monday, September 18, 2017 11:03:37 AM PDT Chris Wilson wrote:
> > Tangential: Do we care about intel_upload_finish on batch flush any more
> > now that async access is universal?
>
> I'm not sure. We could certainly
Quoting Chris Wilson (2017-09-19 09:38:54)
> Quoting Kenneth Graunke (2017-09-18 21:44:57)
> > On Monday, September 18, 2017 11:14:35 AM PDT Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2017-09-18 18:56:57)
> > > > @@ -904,13 +914,6 @@ _intel_batchbuffer_
Quoting Jason Ekstrand (2017-09-24 22:53:04)
> I've got this a few times recently and it's really annoying. I don't know
> if this will fix anything or not but it may be worth a go. I fear,
> however, that ignoring an execbuf failure will lead to permanently
> corrupted rendering or even addit
han post-increment, so we
> change screen->program_id to be initialized to 0 instead of 1. At which
> point, we can just delete the initialization because intel_screen is
> rzalloc'd.
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing
Quoting Kenneth Graunke (2017-09-24 07:02:03)
> There's no real advantage or disadvantage here, it's just for stylistic
> consistency with the rest of the codebase.
Being consistent is its own reward.
Reviewed-by: Chris Wilson
-Chris
Quoting Kenneth Graunke (2017-09-24 07:02:05)
> do_flush_locked isn't a great name - especially given that there's no
> locking going on in our code relating to execbuf.
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev maili
Quoting Kenneth Graunke (2017-09-25 17:46:11)
> On Monday, September 25, 2017 8:05:29 AM PDT Chris Wilson wrote:
> > Quoting Jason Ekstrand (2017-09-24 22:53:04)
> > > I've got this a few times recently and it's really annoying. I don't
> > > know
>
Quoting Rogovin, Kevin (2017-09-26 10:35:44)
> Hi,
>
> Attached to this message are the following:
> 1. a file giving example usage of the tool with a modified apitrace to
> produce json output
>
> 2. the patches to apitrace to make it BatchbufferLogger aware
>
> 3. the JSON fi
Quoting Rogovin, Kevin (2017-09-27 07:53:29)
> Hi,
>
> Right now the way the thing works is that it walks the batchbuffer just
> after the kernel returns from the ioctl and updates its internal view of the
> GPU state as it walks and emits to the log file the data. The log on a single
> batchb
Quoting kevin.rogo...@intel.com (2017-09-25 11:34:06)
> +static
> +uint32_t
> +intel_batchbuffer_state(const struct i965_logged_batchbuffer *st)
> +{
> + struct intel_batchbuffer *batch
> + = (struct intel_batchbuffer*) st->driver_data;
> +
> + assert(batch->bo->gem_handle == st->gem_bo);
Quoting Boris Brezillon (2017-09-27 14:45:17)
> static struct vc4_bo *
> vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const char *name)
> {
> @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, uint32_t
> size, const char *name)
> return NUL
Quoting Boris Brezillon (2017-09-27 15:06:53)
> On Wed, 27 Sep 2017 14:50:10 +0100
> Chris Wilson wrote:
>
> > Quoting Boris Brezillon (2017-09-27 14:45:17)
> > > static struct vc4_bo *
> > > vc4_bo_from_cache(struct vc4_screen *screen, uint3
Quoting Rogovin, Kevin (2017-09-27 15:22:00)
> Hi,
>
> > Hmm, this needs updating for the batch/state split;
>
> This was rebased (and working) against Mesa of Monday, Sept 25, 2017, which I
> thought already had the batchbuffer split. I had thought the split was
> already in master... but why
Mention to the debug log if the kernel scheduler is enabled; and in
particular if it has preemption enabled.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Ben Widawsky
---
src/mesa/drivers/dri/i965/intel_screen.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa
river, the EGLContext will remain at medium
priority.
Signed-off-by: Chris Wilson
Cc: Rob Clark
Reviewed-by: Ben Widawsky
Reviewed-by: Emil Velikov
Reviewed-by: Eric Engestrom
---
include/GL/internal/dri_interface.h | 8 +
src/egl/drivers/dri2/egl_dri2.c | 5
src/egl/mai
setting to medium, we can faithfully report any error
whilst setting without worrying about kernel version.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 18 ++
src/mesa/drivers/dri/i965/brw_bufmgr.h | 9 +
src/mesa/drivers/dri
Mention to the debug log if the kernel scheduler is enabled; and in
particular if it has preemption enabled.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Ben Widawsky
Reviewed-by: Joonas Lahtinen
---
src/mesa/drivers/dri/i965/intel_screen.c | 11 +++
1 file changed, 11
Pulling in changes from upto
kernel commit 5f3b6efaabcd917a778dc924208bcf8f5319bef3
Author: Chris Wilson
Date: Wed Oct 26 22:00:57 2016 +0100
drm/i915/scheduler: Support user-defined priorities
for implementing IMG_context_priority.
Signed-off-by: Chris Wilson
---
include/drm-uapi
version and privilege) and we should only have to do it once
during screen setup -- although the SETPARAM should be fast, they are
still an ioctl each.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Reviewed-by: Emil Velikov
---
src/mesa/drivers/dri/i965/intel_screen.c | 13 +
1 file
Suggested-by: Emil Velikov
Signed-off-by: Chris Wilson
---
docs/relnotes/17.3.0.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/relnotes/17.3.0.html b/docs/relnotes/17.3.0.html
index 4a74284632..6a0a4735a8 100644
--- a/docs/relnotes/17.3.0.html
+++ b/docs/relnotes/17.3.0.html
checked at
the user boundary.)
Signed-off-by: Chris Wilson
Acked-by: Ben Widawsky # i915/i965
Reviewed-by: Emil Velikov
Reviewed-by: Eric Engestrom
---
include/GL/internal/dri_interface.h| 6
src/egl/drivers/dri2/egl_dri2.c| 38 +-
src
Quoting Emil Velikov (2017-09-29 13:03:03)
> Hi Chris,
>
> On 29 September 2017 at 11:25, Chris Wilson wrote:
> > Pulling in changes from upto
> >
> > kernel commit 5f3b6efaabcd917a778dc924208bcf8f5319bef3
> Which tree is this SHA1 based on? I cannot find it in
Quoting Kenneth Graunke (2017-09-29 20:55:53)
> On Friday, September 29, 2017 3:25:09 AM PDT Chris Wilson wrote:
> > Hook up the RendererQuery for __DRI2_RENDERER_HAS_CONTEXT_PRIORITY to
> > report the available DRM_I915_GEM_CONTEXT_SETPARAM options based on the
> > the defaul
Quoting Chris Wilson (2017-09-29 21:03:14)
> Quoting Kenneth Graunke (2017-09-29 20:55:53)
> > Typically we wait to pull in new headers until the kernel patches land
> > in airlied's drm-next tree.
>
> drm-intel is a non-rebasing tree, once the commit lands there,
Quoting Kenneth Graunke (2017-09-29 22:59:56)
> On Friday, September 29, 2017 1:03:14 PM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-29 20:55:53)
> > > On Friday, September 29, 2017 3:25:09 AM PDT Chris Wilson wrote:
> > > >
Quoting Kenneth Graunke (2017-10-10 23:14:17)
> +bool
> +brw_blorp_download_miptree(struct brw_context *brw,
> + struct intel_mipmap_tree *src_mt,
> + mesa_format src_format, uint32_t src_swizzle,
> + uint32_t level, uint
Quoting Kenneth Graunke (2017-10-10 23:14:17)
> +/* Consider all the restrictions and determine the format of the source. */
> +static mesa_format
> +blorp_get_client_format(struct brw_context *brw,
> +GLenum format, GLenum type,
> +const struct gl_pi
Quoting Kenneth Graunke (2017-10-13 08:38:15)
> This really makes more sense in the intel_batchbuffer struct.
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/m
Quoting Kenneth Graunke (2017-10-13 08:38:14)
> fast_clear_op is leftover from the meta-fast-clear days.
> No idea what the other thing was for, but it isn't used now.
Simply mechanics so no great insight required, I hope,
Reviewed-by: Chris Wil
Technically only for Sandybridge and later core designs, but finally we
can claim support for allowing clients to create glBufferObjects from
their own memory.
---
docs/relnotes/17.3.0.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/relnotes/17.3.0.html b/docs/relnotes/17.3.0.html
in
Since v3.16 (though universal access was only enabled by default in v4.6),
the kernel has offered the ability to wrap any system memory (i.e. RAM
and not I/O mapped memory) into an object that can be used by the GPU. The
caveat is that this object is marked as cache coherent (so that the client
can
We know that we will only ever need to lookup an external handle and so
can defer adding a bo to the external ht until it is ever exported or
imported, keeping that hashtable compact.
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 36 +++---
1 file c
All GEN GPU can bind to any piece of memory (thanks UMA), and so through
a special ioctl we can map a chunk of page-aligned client memory into
the GPU address space. However, not all GEN are equal. Some have
cache-coherency between the CPU and the GPU, whilst the others are
incoherent and rely on s
The primary benefit for this is that we get format conversion for
"free", along with detiling and cache flushing (most relevant for !llc).
Using the GPU does impose a bandwidth cost that is presumably better
used for rendering, hence we limit the use to readback into client
memory (not pbo) where w
Recent kernels do exclude snoop access for i965g/i965gm as it does not
work as advertised. However to avoid depending on a recent kernel for
old hardware, mark the presence of the bug in gen_device_info.
See kernel commit df0700e53047662c167836bd6fdeea55d5d8dcfa
Author: Chris Wilson
Date: Wed
hives/mesa-dev/2015-August/091077.html
But we do want to share the bufmgr between screens, and you do want to
deprecate the current intel_batchbuffer.c due to the very large overhead
it imposes.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
APPLE when called with
glObjectUnpurgeable(GL_UNDEFINED_APPLE).
Testcase: piglit/object_purgeable-api-*
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_object_purgeable.c | 36 ++--
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/src/mesa/driver
Not much has changed in the couple of years since last posting, just a
lot of rebasing.
Still the major open question is how much locking do individual contexts
require amongst a shared set - can we rely of the upper layer providing
sufficient serialisation around access to brw_context?
The 40% i
sters without a full batch flush.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/gen7_sol_state.c | 13 -
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
3 files changed, 14 insertions(+), 1 del
Upcoming patches eliminate the intel_batchbuffer interface and one of
the minor changes that causes a lot of churn is the removal of the
header, along with the occassional need to now call intel_reg.h
themselves. This patch moves the individual includes into brw_context.h.
Signed-off-by: Chris
nd bo for the context since
the context itself is owned by the screen (and so we can rely on the bo
existing for the lifetime of the context).
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Martin Peres
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri
gen7_sol_state loads the SOL_OFFSET registers from its scratch buffer
by hand, switch it over to the common routine for emitting that command.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff
In order to reduce future churn, rename the intel_batchbuffer struct.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 4 ++--
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/brw_state_batch.c | 6 ++
src/mesa/drivers/dri
Simple rename and parameter passing changes now to avoid doing so inside
a much larger patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 5 +
src/mesa/drivers/dri/i965/brw_context.c | 12 ++
src/mesa/drivers/dri/i965/brw_context.h
In order to reduce later churn, move a few parameters from the general
brw_context into the intel_batchbuffer.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 20 +
src/mesa/drivers/dri/i965/brw_compute.c | 2 +-
src/mesa/drivers/dri/i965
To further reduce churn when replacing the buffer object implementation,
wrap the existing drm_intel_bo_reference/drm_intel_bo_unreference.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 12 ++
src/mesa/drivers/dri/i965/brw_context.c | 29
is ordered after earlier pipe control writes.
Testcase: piglit/arb_query_buffer_object-qbo/*async*
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
Since brw_batch will become the dominate interface for brw_bo, move the
pointer now to reduce later churn.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 2 ++
src/mesa/drivers/dri/i965/brw_binding_tables.c | 2 +-
src/mesa/drivers/dri/i965/brw_context.c
To reduce churn later, move the brw->render_cache dirty set into the
batch (i.e. brw->batch.render_cache).
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 7 +++
src/mesa/drivers/dri/i965/brw_context.h | 7 ---
src/mesa/drivers/dri/i965/intel_fbo.c
In preparation for the next patch, just transplant some functions
between header files.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 17 +
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 18 --
2 files changed, 17 insertions
If we have to flush the batchbuffer early that has performance
implications, and if it is a result of user action we should report that
through the perf_debug interface.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 3 ++
src/mesa/drivers/dri/i965
To ease future transitions.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 32
src/mesa/drivers/dri/i965/brw_context.h | 32
2 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/src/mesa
In preparation for a local batch manager with a new buffer object, first
reduce the churn by renaming the existing buffer objects:
s/drm_intel_bo/brw_bo/
We only have to be careful to leave the global screen drm_intel_bo as
they are.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965
In order to reduce future churn, move the callbacks for starting and
finishing the batch from intel_batchbuffer to the brw_context.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.c | 83 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 79
We only need the batch promotion if we need to modify privileged registers,
so only request it when we do register loads and stores.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.c | 7 ++-
src/mesa/drivers/dri/i965/brw_batch.h | 2 ++
src
To ease intermediate patches.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 2 ++
src/mesa/drivers/dri/i965/brw_compute.c | 4 ++--
src/mesa/drivers/dri/i965/brw_context.h | 1 -
src/mesa/drivers/dri/i965/brw_draw.c | 4 ++--
src/mesa
address into the state with a convenient helper.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 54 ++
src/mesa/drivers/dri/i965/brw_cc.c | 14 ++---
src/mesa/drivers/dri/i965/brw_clip_state.c | 14 ++---
src/mesa/drivers/dri
Just to ease the next intermediate patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 1 +
src/mesa/drivers/dri/i965/brw_compute.c | 6 +--
src/mesa/drivers/dri/i965/brw_draw.c | 7 ++--
src/mesa/drivers/dri/i965/brw_state_batch.c | 6
Process the postdraw resolves (including setting the buffer dirty flag)
before any conditional batch flush as that flush will want to clear the
dirty flag.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_draw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
To reduce later churn, extract drm_intel_bo_madvise() with a smaller
wrapper.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 5 +
src/mesa/drivers/dri/i965/brw_object_purgeable.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src
Simple non-functional change to ease later patches.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 26 ++
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 26 --
2 files changed, 26 insertions(+), 26 deletions
Rather than passing the uint64_t value to write as a pair of high/lo
uint32_t values, place the burden on the callee to split the large value
into the dwords desired by the hardware.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +--
src/mesa/drivers/dri/i965
ff-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_conditional_render.c | 5 +
src/mesa/drivers/dri/i965/brw_queryobj.c | 15 +++
src/mesa/drivers/dri/i965/brw_state_upload.c | 13 +++--
src/mesa/drivers/dri/i965/gen6_queryobj.c
The flags field becomes more useful later as we store more bits in it,
but for now we can start it off with the pair of boolean state already
stored inside batch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 5 +++--
src/mesa/drivers/dri/i965/brw_misc_state.c
Rather than spend an instruction deciding whether we need to, just zero
out the single integer to reset the HW binding tables.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_binding_tables.c | 6 --
src/mesa/drivers/dri/i965/brw_context.c| 3 +--
src/mesa/drivers/dri
601 - 700 of 1057 matches
Mail list logo
