We have many flushes outside of the batch buffer critical sections that
need wrapping. Introduce a simple function to wrap the brw_emit_mi_flush()
with the begin/end.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_clear.c| 4 +--
src/mesa/drivers/dri/i965
With mesa/drm commit cd2f91e18db087edf93fed828e568ee53b887860
Author: Kristian Høgsberg Kristensen
Date: Fri Jul 31 10:47:50 2015 -0700
intel: Drop aub dumping functionality
the drm_intel_aub routines are mere stubs and do nothing. Likewise
remove our invocations.
Signed-off-by: Chris
Churn now to reduce churn later.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 34 +
src/mesa/drivers/dri/i965/brw_binding_tables.c | 3 +-
src/mesa/drivers/dri/i965/brw_context.c | 3 +-
src/mesa/drivers/dri/i965/brw_program.c
Since we use fences internally for tracking buffer busyness within
brw_batch.c, we can expose those directly for GL/DRI2 sync objects.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.c | 87 --
src/mesa/drivers/dri/i965/brw_batch.h | 22 -
src/mesa
Since we always flush the intel_batchbuffer before calling
intel_front_flush(), simply more that call into intel_front_flush()
itself.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/mesa
-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_binding_tables.c | 3 ++-
src/mesa/drivers/dri/i965/brw_program.c| 2 +-
src/mesa/drivers/dri/i965/brw_queryobj.c | 9 ++---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 3 ++-
src/mesa/drivers/dri/i965/gen6_sol.c
generic routine for storing the register values
found in gen6_queryobj.c which we can transplant into the new pipelined
mmio file.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/Makefile.sources | 2 +
src/mesa/drivers/dri/i965/brw_compute.c| 1 +
src/mesa/drivers
Refactor the aperture test, roll back and retry logic to a common idiom.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 18
src/mesa/drivers/dri/i965/brw_compute.c | 36 +++-
src/mesa/drivers/dri/i965/brw_draw.c | 33
lobal GTT workaround, essentially 2 bits of information. We can therefore
trim a parameter by coalescing the relocation domains to a single unsigned
bitfield (i.e. 32 bits of read/write domains rather than 64 bits) without
loss of generality.
Signed-off-by: Chris Wilson
---
src/intel/blorp/bl
Rather than split the render batch setup between two hooks, coalesce it
into a single callback. To simplify this, move some of the state
dirtying from the start to the finish hook hook.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.c | 15 ++-
src/mesa
We can use our fence tracking mechanism for fine-grained waiting on
results.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_conditional_render.c | 4 +-
src/mesa/drivers/dri/i965/brw_context.c| 2 +
src/mesa/drivers/dri/i965/brw_context.h| 10 +-
src
Provide a common routine for doing conditional batch flushes.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 6 ++
src/mesa/drivers/dri/i965/brw_compute.c | 3 +--
src/mesa/drivers/dri/i965/brw_draw.c| 3 +--
src/mesa/drivers/dri/i965
situation.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_structs.h | 137 +---
1 file changed, 89 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_structs.h
index 55338c0e24
Remove the old hashtable approach and switch over to the inline write
tracking with brw-batch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.c | 70 ++-
src/mesa/drivers/dri/i965/brw_batch.h | 10 +---
src/mesa/drivers/dri/i965
Just to reduce some later churn, pull out the flink wrapper.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 7 +++
src/mesa/drivers/dri/i965/brw_context.c | 11 +--
src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
3 files changed, 13 insertions(+), 7
A simple helper to check whether the last batch buffer submitted to the
hardware is still busy. Extract it now to reduce churn later.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 5 +
src/mesa/drivers/dri/i965/brw_cs.c| 5 ++---
src/mesa/drivers/dri/i965
Move the computation of the state offset into a smaller helper to reduce
churn later.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_state_dump.c | 62 --
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
We have a few instances where we set a register to an immediate value
(MI_LOAD_REGISTER_IMM), so let's replace them with a simple routine.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_draw.c | 6 +-
src/mesa/drivers/dri/i965/brw_state_upload.c | 11 +--
To reduce churn later, move the HW context variable from brw_context to
brw_batch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 2 ++
src/mesa/drivers/dri/i965/brw_context.c | 23 --
src/mesa/drivers/dri/i965/brw_context.h | 2
Or rather export a higher level brw_pipe_control_flush() that wraps the
brw_emit_pipe_control_flush() into a batch as appropriate for the
caller.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_pipe_control.c | 9 +
src
The gen7 transform feedback routines store the SOL_OFFSET between
batches into its scratch buffer. Convert these from using opencoded
brw_store_register_mem32()
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 10 +++---
src/mesa/drivers/dri/i965/hsw_sol.c
Since we can distinguish when mapping between READ and WRITE, we can
pass along the map mode to avoid stalls and flushes where possible.
Signed-off-by: Chris Wilson
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 +++
1 file changed
On Wed, Jan 11, 2017 at 10:16:06AM +0200, Martin Peres wrote:
> On 10/01/17 23:23, Chris Wilson wrote:
> >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 co
*/
> - if (brw->gen < 8) {
Would not
if (brw->gen < 8 &&
!(brw_is_drawing_points(brw) || brw_is_drawing_lines(brw)))
by itself fix the misrendering as a first step without any concern for
wider impact?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
n all platforms. On non-LLC
> > platforms, we simply need to clflush after memcpy'ing in new shaders,
> > so they're visible to the GPU. This is not only better, but the code
> > is also significantly simpler.
Or just use a WC mapping, for even greater simpli
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
Cc: Chad Versace
Cc: Daniel Vetter
---
src/mesa/drivers/dri/i965/Makefile.am
On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote:
> On Thu 26 Jan 2017, Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
> >
> >
On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote:
> On Thu 26 Jan 2017, Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
> >
> >
On Fri, Jan 27, 2017 at 06:20:46PM +, Emil Velikov wrote:
> On 27 January 2017 at 00:01, Chad Versace wrote:
> > On Thu 26 Jan 2017, Chad Versace wrote:
> >> On Thu 26 Jan 2017, Chris Wilson wrote:
> >> > Since the workaround bo is used strictly as a write-on
ecified by STATE_BASE_ADDRESS will
> +* over-flow the 48-bit address range, and the GPU will hang. In order to
> +* avoid this problem, we tell the kernel that the buffer does not support
> +* 48-bit addresses, and it places the buffer at a 32-bit address. While
> +* this solution is probably overkill, it is effective.
How about just setting the field to the bo->size? You must know the bo
already at that point so that you can set the relocation target.
Or you could allocate the sparse trtt in the high range and the kernel
will then never be able to place objects high enough to overflow. I
presume the overflow of the bo base + limit into the trtt will not cause
similar issues...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Mar 29, 2017 at 08:36:36AM -0700, Jason Ekstrand wrote:
>On Wed, Mar 29, 2017 at 1:51 AM, Chris Wilson
><[1]ch...@chris-wilson.co.uk> wrote:
>
> On Tue, Mar 28, 2017 at 05:41:12PM -0700, Jason Ekstrand wrote:
> > This commit adds support for using
On Wed, Mar 29, 2017 at 04:51:12PM +0100, Chris Wilson wrote:
> On Wed, Mar 29, 2017 at 08:36:36AM -0700, Jason Ekstrand wrote:
> >On Wed, Mar 29, 2017 at 1:51 AM, Chris Wilson
> ><[1]ch...@chris-wilson.co.uk> wrote:
> > > diff --git a/src/intel/vulka
was won over at having pager support. I was getting close to moving
the decoder to mesa myself, though it would have been a much less
refined effort!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev
ntext_param p;
size_t mappable_size, aper_size;
memset(&p, 0, sizeof(p));
p.param = I915_CONTEXT_PARAM_GTT_SIZE;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &p) == 0)
return p.value;
/* do sometheing useful for old kernels */
drm_intel_g
e is *meaningless* with full-ppgtt. But if libdrm is limiting
your batchbuffers using its result, than that is the maximum usable
memory for GL (whilst it remains using libdrm_intel batchbuffers). :(
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
onger busy. If we haven't seen availability yet,
> + * then we never will.
> + */
> + return query_is_available(device, slot) ? VK_SUCCESS : VK_NOT_READY;
> + case VK_TIMEOUT:
> + /* The BO is still busy, keep waiting. */
> +
ing get_aperture so
that it matches the batch space calculation used by libdrm, and the
reminder that once that is lifted, this can be replaced.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesk
On Tue, Apr 04, 2017 at 05:09:52PM -0700, Kenneth Graunke wrote:
> This does nothing on Gen4+, which is the only hardware we support.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
m
accessible. A wayland
compositor + gbm could allocate all framebuffers from stolen -- it's
an issue of protocol, both parties must be aware that certain bo are not
first class.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> We rename intel_bufmgr.h to brw_bufmgr.h to avoid #include conflicts.
> We also fix UTF-8 symbol problems in intel_bufmgr_gem.c comments
> because vim keeps trying to fix that every time I edit the file,
> and we may as well fix it right away.
Acked-by: Chris Wilson
I was dreaming of way
e for post-mortem debugging. Instead of trying to emit a
continous description/replay, just capture a description for each batch
and include it in the error state.
That's my wishful thinking.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
Slightly less invasive?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
as far as I can tell, it has never been fixed) about
how using libpciaccess from libdrm_intel breaks the world (since
libpciaccess uses a singleton that is torn down at the first request
rather than upon the last user).
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source T
;
> Signed-off-by: Kenneth Graunke
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
EX_INITIALIZER;
> -static drmMMListHead bufmgr_list = { &bufmgr_list, &bufmgr_list };
> +static struct list_head bufmgr_list = { &bufmgr_list, &bufmgr_list };
A missing opportunity for static LIST_HEAD(bufmgr_list)?
Looks mechanical as expected,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 04, 2017 at 05:10:02PM -0700, Kenneth Graunke wrote:
> Based on a patch by Kristian Høgsberg.
Even a token explanation "These functions are unused, remove them from
the build. More to come later after refactoring!" ?
Seems small!
Reviewed-by: Chris Wilson
-Chris
--
On Tue, Apr 04, 2017 at 05:10:04PM -0700, Kenneth Graunke wrote:
> execbuf2 has been around for years.
since v2.6.33, comformtably older than the current minimum supported
kernel version.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Cen
construction. All the
related fence functions are unused.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 04, 2017 at 05:10:05PM -0700, Kenneth Graunke wrote:
> ROUND_UP_TO handles a NPOT alignment, but all the alignments we use
> are power of two anyway, so there's no need.
Slightly better than the kernel's roundup and round_up!
Reviewed-by: Chris Wilson
-Chris
--
Chr
Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 04, 2017 at 05:10:07PM -0700, Kenneth Graunke wrote:
> Eliminates some API around this, and more importantly, the last
> field in one bufmgr class.
Nice. Some quirms that it is using DEBUG_BUFMGR for batch tracking
rather than buffer handling, but
Reviewed-by: Chris Wilson
orting the old crap you get a \o/ for every
removal.)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 04, 2017 at 05:10:09PM -0700, Kenneth Graunke wrote:
> Legacy DRI1 leftovers.
Do you want to convert intel_batch.c to only using one exec function,
then remove all the others in one fell swoop?
Nevertheless,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Sou
On Tue, Apr 04, 2017 at 05:10:10PM -0700, Kenneth Graunke wrote:
> This moves us one step closer to killing off intel_bufmgr_priv.h.
And please hint you will be killing drm_bacon_context!
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Cen
On Tue, Apr 04, 2017 at 05:10:11PM -0700, Kenneth Graunke wrote:
The distinction was required when the bufmgr was virtualised, now there
is only one class, we no longer need the distraction of pretending it is
a subclass.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source
On Tue, Apr 04, 2017 at 05:10:12PM -0700, Kenneth Graunke wrote:
> This query has been available since 2.6.28. We require 3.6.
Sure, get-aperture is still misleading though ;)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Cen
On Tue, Apr 04, 2017 at 05:10:13PM -0700, Kenneth Graunke wrote:
> We require Kernel 3.6 and fail screen creation if this doesn't exist.
The wait-ioctl was introduced in kernel v3.6 (20120930) and that is our
current minimum requirement for screen creation.
Reviewed-by: Chris Wilson
On Tue, Apr 04, 2017 at 05:10:14PM -0700, Kenneth Graunke wrote:
> This field was the wrong size, so we replaced it with offset64.
Reviewed-by: Chris Wilson
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.h | 6 --
> src/mesa/drivers/dri/i965/intel_bufmgr_gem.c | 3 ---
Reviewed-by: Chris Wilson
We are still managing multiple pci-id lists. We gave ourselves the goal
many, many years ago of having a single canonical list.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lis
On Tue, Apr 04, 2017 at 05:10:16PM -0700, Kenneth Graunke wrote:
> This is basically handholding to prevent a bogus caller from trying to
> execbuffer on a bogus engine. i965 already does this correctly.
Too true.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Tech
lot faster using the format conversion
with blorp than mesa, even with the synchronisation cost. (I thought I
sent the userptr integration along with brw_batch?)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 04, 2017 at 05:10:20PM -0700, Kenneth Graunke wrote:
> It's always zero now.
Reviewed-by: Kenneth Graunke
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.o
On Tue, Apr 04, 2017 at 05:10:19PM -0700, Kenneth Graunke wrote:
> Mesa doesn't use this yet. We'll almost certainly want to, but we can
> add the functionality back after we clean up the messy drm code.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source T
alablity is far more
important. It used to be a linear list which for a stress test of many
hundreds of thousands of bo was unconscionable.
I choose uthash simply for its license and convenience. Mesa should have
a dense integer focused hash/idr. (And one day it will ;)
Reviewed-by: Chris Wil
On Tue, Apr 04, 2017 at 05:10:22PM -0700, Kenneth Graunke wrote:
> This used to have another field, but now it's just a BO pointer.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing l
ship of those handles is shared by those independent parties.
*
* Don't do this! Ensure that each library/bufmgr has its own device
* fd so that its namespace does not clash with another.
*/
Hmm, not great. The point about namespaces is ok, but the danger is the
blurb is more confusi
s. Drop the code.
Reviewed-by: Chris Wilson
(Still pining for a few assert(!bo->scanout || !write);)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/m
intel_batchbuffer *batch, uint32_t batch_offset,
> + drm_bacon_bo *target, uint32_t target_offset,
> + uint32_t read_domains, uint32_t write_domain)
Names make sense, but target_offset limited to u32? I hope that's on
your today list. (As well as sto
he bugs are kept.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
h the bo.
As a simple name change,
Reviewed: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
this when we rewrite aperture space checking, shortly.
> In the meantime, we can also use it in GLX_MESA_query_renderer.
This patch could be applied now, since it is moving the query from
runtime to screen init.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open S
nt = 2,
> + .batch_len = ALIGN((char *) batch - (char *) bo->virtual, 8),
> + .flags = I915_EXEC_RENDER,
> + };
> +
> + __DRIscreen *dri_screen = screen->driScrnPriv;
> + drmIoctl(dri_screen->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &e
> +}
> +
> +bool
> brw_batch_references(struct intel_batchbuffer *batch, drm_bacon_bo *bo)
> {
> - return drm_bacon_bo_references(batch->bo, bo);
> + for (int i = 0; i < batch->exec_count; i++) {
> + if (batch->exec_bos[i] == bo)
> + return t
? Is there a reason why the drm_bacon_bo/drm_bacon_gem_bo has
remained so long? At the moment they are the same global information.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@
On Tue, Apr 04, 2017 at 05:10:32PM -0700, Kenneth Graunke wrote:
> The separate class gives us a bit of extra encapsulation, but I don't
> know that it's really worth the boilerplate. I think we can reasonably
> expect the rest of the driver to be responsible.
Reviewed-by: Chr
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 04, 2017 at 05:10:34PM -0700, Kenneth Graunke wrote:
> Mesa style is to not use lengthy prefixes for static functions.
All the types are wrong. :( Please fix this inherited mess.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Cen
On Tue, Apr 04, 2017 at 05:10:35PM -0700, Kenneth Graunke wrote:
> No need for a prefix as this struct is local to the .c file.
>
> Less bacon.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-de
, DRM_IOCTL_I915_GET_RESET_STATS, stats))
err = -errno;
return err; /* reporting the actual error may be
overkill, just habit! */
}
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
if (ctx_id != 0 &&
> + drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_DESTROY, &d) != 0) {
> fprintf(stderr, "DRM_IOCTL_I915_GEM_CONTEXT_DESTROY failed:
> %s\n",
Reviewing the fprintf I hope are on the todo list.
Reviewed-by: Chris
On Tue, Apr 04, 2017 at 05:10:39PM -0700, Kenneth Graunke wrote:
> Less bacon.
brw_reg_read() now doesn't need to be part of the bufmgr.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
BO map
> function itself, so all callers gain the warning.
I plumbed your perf_debug into the lower layers to maintain the stall
warnings. Would that not be a better approach?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev
fort into trying to
explain why brw_batch.c behaves as it does and how it expects the kernel
to behave in relation to itself. Those comments are probably more
valuable than the code contributions...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Wed, Apr 05, 2017 at 09:37:16AM -0700, Jason Ekstrand wrote:
>On Wed, Apr 5, 2017 at 1:27 AM, Chris Wilson <[1]ch...@chris-wilson.co.uk>
>wrote:
>
> On Tue, Apr 04, 2017 at 07:21:38PM -0700, Jason Ekstrand wrote:
> > Before, we were just looking at
other thread, I just mentioned a subtlety that GEM_BUSY is
restricted to reporting on i915.ko GPU users of the bo, whereas GEM_WAIT
will report on the status of all users, including third parties and
miscellaneous asynchronous tasks.
-Chris
--
Chris Wilson, Intel Open Source Technology
t the bo is idle, you might then went to
check for a reset in case it was due to a lost device. GEM_BUSY is
lockless, but GEM_RESET_STATS currently takes the big struct_mutex and
so has non-deterministic and often quite large latencies.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Apr 05, 2017 at 11:02:18AM -0700, Jason Ekstrand wrote:
>On Wed, Apr 5, 2017 at 10:45 AM, Chris Wilson
><[1]ch...@chris-wilson.co.uk> wrote:
>
> On Wed, Apr 05, 2017 at 10:28:53AM -0700, Jason Ekstrand wrote:
> > Before, we were just looking at
rs.
> >> >
> >> I believe I mentioned it a few days ago - there is no need to worry
> >> about API or ABI stability.
> >>
> >> Need new API - add it. Things getting fragile or too many layers -
> sed
> >> /libdrm_intel$(N)/libdrm_intel$(N+1)/ and rework as needed.
> >>
> >> I fear that Importing libdrm_intel will be detrimental to libva's
> >> intel-driver, Beignet and xf86-video-intel
>
>I wouldn't worry about xf86-video-intel. Chris has already copy+pasted
>half of the X server, what's libdrm? :-)
Slight overexaggeration, but that libdrm_intel was snafu was the original
split.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
on
> each query until it's available.
>
> This significantly reduces pipeline bubbles and improves performance of
> The Talos Principle on medium settings (where the GPU isn't overloaded
> with drawing) by around 20% on my SkyLake gt4.
I've no more hopefully helpful s
gt;
>
> LIBGL_DEBUG=verbose glxgears
> libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
> libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> libGL: Can't open configuration file /home/lkcl/.drirc: No such file
> or directory.
> li
On Wed, Apr 05, 2017 at 02:36:38PM -0700, Kenneth Graunke wrote:
> On Wednesday, April 5, 2017 3:33:39 AM PDT Chris Wilson wrote:
> > On Tue, Apr 04, 2017 at 05:10:15PM -0700, Kenneth Graunke wrote:
> > > This moves the PCI ID detection to intel_screen.c and makes
> > >
On Wed, Apr 05, 2017 at 04:56:42PM -0700, Kenneth Graunke wrote:
> On Wednesday, April 5, 2017 4:46:27 AM PDT Chris Wilson wrote:
> > On Tue, Apr 04, 2017 at 05:10:30PM -0700, Kenneth Graunke wrote:
> > > The execbuf2 kernel API requires us to construct two kinds of lists
On Thu, Apr 06, 2017 at 12:04:40PM +0100, Lionel Landwerlin wrote:
> This is a pretty good indicator that something's gone horribly wrong.
Do you run IPEHR through the decoder? That was somewhere on the todo
list for intel_error_decode.
-Chris
--
Chris Wilson, Intel Open Source Te
On Thu, Apr 06, 2017 at 12:17:00PM +0100, Lionel Landwerlin wrote:
> On 06/04/17 12:12, Chris Wilson wrote:
> >On Thu, Apr 06, 2017 at 12:04:40PM +0100, Lionel Landwerlin wrote:
> >>This is a pretty good indicator that something's gone horribly wrong.
> >Do you run IP
e!
Signed-off-by: Chris Wilson
Reviewed-by: Tapani Pälli
Cc: Rob Clark
---
src/egl/drivers/dri2/egl_dri2.c | 1 +
src/egl/main/eglapi.c | 2 ++
src/egl/main/eglcontext.c | 30 ++
src/egl/main/eglcontext.h | 1 +
src/egl/main/egldisplay.h
driver as a function parameter.
Issues:
* How to pass back the priority of the create context (as it may be
modified by the driver) back to EGL?
Signed-off-by: Chris Wilson
---
include/GL/internal/dri_interface.h| 6
src/egl/drivers/dri2/egl_dri2.c| 38
>if (sscanf(line, "%m[^ ] command stream\n", &new_ring_name) > 0) {
> @@ -356,7 +357,7 @@ read_data_file(FILE *file)
> ring_name = new_ring_name;
>}
Just handle ascii85_start here, they are unique line[0].
decode() needs a few fixes to use the
;
anv_multialloc_add(&ma, &set_layout, 1);
anv_multialloc_add(&ma, &bindings, max_binding + 1);
anv_multialloc_add(&ma, &samplers, immutable_sampler_count);
if (!anv_multialloc_alloc(&ma,
&device->alloc ?:
invalidate_range(pool->bo.map + offset,
> - MIN2(size, pool->bo.size - offset));
> - }
> -
> VkResult status = VK_SUCCESS;
> for (uint32_t i = 0; i < queryCount; i++) {
>uint64_t *slot = pool->bo.map + (firstQuery + i) * pool->stride;
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
701 - 800 of 1057 matches
Mail list logo
