b___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Dear
Could anyone tell me where is the "wl_drm_create" function defined? I can't
find it anywhere, no definition can be found. No google information can be
searched! Why?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop
Dear Kristian,
I have found no drm.xml in mesa code.
Do you means wayland-drm.xml under "src/egl/wayland/wayland-drm/protocol".
At 2011-10-18 23:55:18,"Kristian Høgsberg" wrote:
>2011/10/18 chris :
>> Dear
>>
>> Could anyone tell me where is the "wl
server side wayland changes
Follow changes in c661ecce1089000c3fca9a543713f8264221be50.
Now the mesa code seems compatible with the wayland 0.8.
Thank you Benjamin
At 2011-10-19 04:53:16,"Benjamin Franzke"
wrote:
>2011/10/18 chris :
>> Dear
>>
>> Could anyone tell
I am a developer on Linux, I found my mesa 8.0 built in my ubuntu not work
properly. My card is NVidia GT73 card. Many glapis are executed with no result
or error result, such as GenFramebufferEXT, eglBindTexImage.
Is there any benchmark tool released with mesa project that can check if mesa
su
In file of "src/gallium/state_trackers/egl/x11/native_dri2.c"
How can I enable the GLX_DIRECT_RENDERING definition in configure time.
GLX_DIRECT_RENDERING is defaultly no defined. so x11_create_dri2_display() is
empty.
My OS is ubuntu 10.04 lucid.
Can someone help me?
__
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
I've added the rb's and tb's locally.
> > >
> > > So IMO, Rafael is a great person to review this. He's underselling his
> > > knowledge
> > > to his detriment. Is there something preventing pushing these patches?
> >
> > I belie
This looks like it misses the interactions with texture completeness.
- Chris
On Wed, Feb 1, 2017 at 7:53 AM, Plamena Manolova wrote:
> This extension provides a new texture and sampler parameter
> (TEXTURE_REDUCTION_MODE_ARB) which allows applications to produce a
> filtered texel
&device->alloc);
> + break;
> + default:
> + break;
> + }
> + }
Seperate in/out arrays curtains the issues I could see with the implicit
fences accidentally serialising input-only semaphores.
-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
ct anv_semaphore_impl *impl = &semaphore->permanent;
> +
> + if (impl->type == ANV_SEMAPHORE_TYPE_SYNC_FILE) {
> +assert(impl->fd == -1);
> +impl->fd = dup(out_fence);
out_fence will still be zero/stdin if anv_device_execbuf() failed.
-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
Nice to see the last remnants of this go.
For the series:
Reviewed-by: Chris Forbes
On Wed, Mar 1, 2017 at 9:53 AM, Kenneth Graunke
wrote:
> In the past, we used this on Gen4-5 to transform non-normalized texture
> coordinates (for sampler2DRect) to normalized ones. We also used
n reset. The permanent semaphore is a
reservation_object (accessed via a bo), it is a volatile collection of
fences that serves as a communication channel between processes.
A synopsis of the differences and use would be invaluable.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
any writes impose a strong ordering between the engines.
(That being the basis of TYPE_BO.)
I don't think it affects anv since there is only a single render queue,
but I think the explanation of TYPE_DUMMY needs a little more fleshing
out to avoid leaving a trap behind.
-Chris
> +
> sync is this broken.
Whilst you are looking at the strange mutex here, can I also tmept you
with
https://cgit.freedesktop.org/~ickle/mesa/commit/?h=fence&id=a50b7115defccfd8239eb39c23c7d7bce720eba7
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
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
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
Reviewed-by: Chris Forbes
On Mon, Jun 13, 2016 at 12:03 PM, Kenneth Graunke
wrote:
> These need to be freed too.
>
> Cc: "12.0"
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 4
> 1 file changed, 4 insertions(+)
>
&
ret < 0 && ret != -EINVAL)
drmIoctl() doesn't return -errno, just -1 and the error code in errno.
-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, Jun 29, 2016 at 09:50:36AM -0700, Chad Versace wrote:
> Stop using drmCommandWriteRead for such a simple ioctl.
>
> v2: Handle errno correctly. [ickle]
Yes, lgtm,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technolo
(The only challenge would language in the spec that
implied that FENCE_FROM_FD steals the fd, for example.)
-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, Jul 12, 2016 at 9:59 PM, Marek Olšák wrote:
+ *endian = r600_endian_swap(32);
I don't fully understand r600, but this 32 seems dubious?
- Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Tue, Jul 19, 2016 at 8:26 AM, Kenneth Graunke
wrote:
> + default:
> + assert(!"invalid intrinsic");
>
unreachable() ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Seems a little unfortunate to add a random bool to this interface which is
otherwise fairly descriptive, but OK.
On Tue, Jul 19, 2016 at 8:26 AM, Kenneth Graunke
wrote:
> While my intention is that the new intrinsics should be usable by all
> drivers, we need to make them optional until all driv
I remember arguing about this when it got added -- tradeoff was payload
size/register pressure vs needing to call out to this unit, if centroid
barycentric coords weren't required for anything else? It does seem fairly
pointless, though.
For the series:-
Reviewed-by: Chris Forbes
On Tue
Oh dear, hacks on both sides. Sorry for this nonsense.
Series is:-
Reviewed-by: Chris Forbes
On Tue, Jul 19, 2016 at 5:16 PM, Jason Ekstrand
wrote:
> From the Sky Lake PRM:
>
>"For SURFTYPE_CUBE: For Sampling Engine Surfaces and Typed Data Port
>Surfaces, the range
d_cookie_t cookie =
> + xcb_present_select_input(draw->conn, draw->eid, draw->drawable,
> + XCB_PRESENT_EVENT_MASK_NO_EVENT);
> +
This throws an error on old Xorg (presuming you've fixed it to work
now), so
cookie = xcb_presen
On Mon, Aug 17, 2015 at 03:17:30PM -0700, Eric Anholt wrote:
> Chris Wilson writes:
>
> > "X rendering calls made prior to glXWaitX are guaranteed to be
> > executed before GL rendering calls made after glXWaitX."
> >
> > The goal is to implement
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
On Sat, Aug 13, 2016 at 12:59:46PM +0100, Chris Wilson wrote:
> If the buffer has been freed by the kernel under memory pressure, it is
> invalid to try and access the backing storage for that buffer in the
> future - the backing storage is not recreated automatically. As such we
>
rime(image->bo, value) == 0)
> - return true;
> - return false;
> + return drm_intel_bo_gem_export_to_prime(image->bo, value) == 0;
Elsewhere in this block we have
return !drm_intel_bo_flink(image->bo, (uint32_t *)value);
so choose betwe
On Mon, Aug 15, 2016 at 03:51:21PM +0100, Eric Engestrom wrote:
> if (x) return true; else return false;
> can be simplified as:
> return x;
> since `x` is already a boolean expression.
>
> Signed-off-by: Eric Engestrom
Both Reviewed-by: Chris Wilson
-Chris
--
C
On Mon, Aug 17, 2015 at 03:17:30PM -0700, Eric Anholt wrote:
> Chris Wilson writes:
>
> > "X rendering calls made prior to glXWaitX are guaranteed to be
> > executed before GL rendering calls made after glXWaitX."
> >
> > The goal is to implement
able, before the backend will use the
surface (either as a texture or as a renderable) it will do a
DRI2GetBuffers() round trip. (It is also likely that the buffer will
have been invalidated in the meantime and alreadly pending the round
trip.) That provides the server with a definite point at which
On Wed, Aug 17, 2016 at 01:34:48PM -0400, Adam Jackson wrote:
> On Wed, 2016-08-17 at 17:50 +0100, Chris Wilson wrote:
> > On Wed, Aug 17, 2016 at 12:13:23PM -0400, Adam Jackson wrote:
> > >
> > > On Wed, 2016-08-17 at 08:17 -0700, Eric Anholt wrote:
> > >
On Wed, Aug 17, 2016 at 06:51:24PM +0100, Chris Wilson wrote:
> However, X will always send a fake front if the real front is requested,
> and the real front buffer is requested if either the read or write
> buffer is GL_FRONT. So the fake front copy should suffice to trigger the
> fl
Now that we have working partial VMA and faulting support for all
objects, including fence support, advertise to userspace that it can
take advantage of unlimited GGTT mmaps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 8
include/uapi/drm/i915_drm.h | 1 +
2
From about kernel 4.9, GTT mmaps are virtually unlimited. A new
parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
feature so query it and use it to avoid limiting tiled allocations to
only fit within the mappable aperture.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src
On Thu, Aug 25, 2016 at 11:00:54AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-08-24 at 20:42 +0100, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -355,6 +355,14 @@ static int i915_getparam(struct drm_device *dev, void
> > *data,
> > cas
On Thu, Aug 25, 2016 at 01:43:53PM -0700, Ian Romanick wrote:
> On 08/24/2016 12:42 PM, Chris Wilson wrote:
> > +#define I915_PARAM_MMAP_GTT_VERSION 40 /* XXX delete me with new libdrm */
> > + if (intel_get_integer(intelScreen, I915_PARAM_MMAP_GTT_VERSION) >= 1) {
> >
and now we do a quick
probe from mesa and use the GL context everywhere, see kernel commit
f7978a0c581a ("drm/i915: Allow the user to pass a context to any ring")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Daniel Vetter
---
src/mesa/drivers/dri/i965/brw_context.c |
This patch isn't right. These enum values are the same as the desktop
version, so your new cases will never actually be used.
On Mon, Aug 29, 2016 at 2:24 AM, Francesco Ansanelli
wrote:
> Signed-off-by: Francesco Ansanelli
> ---
> src/mesa/main/texparam.c | 48 ++
ll not be removed, especially
whitelisted registers, or that all platforms will implement the same set.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.or
-off-by: Chris Wilson
---
include/GL/internal/dri_interface.h | 12 -
src/glx/dri2_glx.c | 16 ++--
src/mesa/drivers/dri/common/dri_util.c | 6 +
src/mesa/drivers/dri/common/dri_util.h | 4 +++
src/mesa/drivers/dri/i965/brw_context.c
the
texture-from-pixmap. This works in DRI2 as texture binding flushes the
rendering to the Pixmap.
Signed-off-by: Chris Wilson
---
src/loader/loader_dri3_helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index
glXWaitX().
References: https://bugs.freedesktop.org/show_bug.cgi?id=97914
Signed-off-by: Chris Wilson
---
src/loader/loader_dri3_helper.c | 44 -
src/loader/loader_dri3_helper.h | 3 +++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/src
On Tue, Oct 25, 2016 at 05:57:14PM +0200, Daniel Vetter wrote:
> On Wed, Oct 19, 2016 at 02:26:15PM -0700, Kenneth Graunke wrote:
> > On Wednesday, October 19, 2016 8:35:11 PM PDT Chris Wilson wrote:
> > > On Wed, Oct 19, 2016 at 12:25:51PM -0700, Kenneth Graunke wrote:
>
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| 36
e!
Signed-off-by: Chris Wilson
---
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 | 2 ++
5 files changed, 36 insertion
Pass along the context priority provided through eglCreateContext to the
kernel, where it will be used for priority sorting of batches.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.c | 43 -
src/mesa/drivers/dri/i965/brw_batch.h | 3
kernel. You already have the buffers
coherently mapped, the kernel doesn't, the kernel needs to copy the
entire relocation tree if even one relocation is wrong, etc.
> Signed-off-by: Jason Ekstrand
> Cc: Kristian Høgsberg
> Cc: Ben Widawsky
> Cc: Daniel Vetter
> Cc: Chri
On Tue, Nov 01, 2016 at 08:07:36AM +, Chris Wilson wrote:
> On Mon, Oct 31, 2016 at 09:48:15PM -0700, Jason Ekstrand wrote:
> > + * By doing relocations on the CPU, we can tell the kernel that it doesn't
> > + * need to bother. We want to do this because the sur
e next MSC, which is the commonly
expected behaviour of apps using glXSwapBuffers() when not overriding the
vblank_mode / swap_interval. To force the frame to be displayed on the
next vblank, we want to pass divisor 1 to the backend.
Signed-off-by: Chris Wilson
Cc: Adam Jackson
---
src/glx/glxcmds.c
On Tue, Nov 01, 2016 at 08:39:16AM -0700, Jason Ekstrand wrote:
>On Tue, Nov 1, 2016 at 1:07 AM, Chris Wilson <[1]ch...@chris-wilson.co.uk>
>wrote:
>
> On Mon, Oct 31, 2016 at 09:48:15PM -0700, Jason Ekstrand wrote:
> > From: Kristian Høgsbe
On Tue, Nov 01, 2016 at 12:58:22PM -0400, Adam Jackson wrote:
> On Sat, 2016-10-22 at 11:00 +0100, Chris Wilson wrote:
>
> > @@ -113,6 +113,11 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable
> > *draw)
> > dri3_free_render_buff
Valgrind reports that we use cfg.cycle_count uninitialised, so zero the
cfg_t on construction.
Fixes: 52d2b28f7f10 ("ralloc: use rzalloc where it's necessary")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Marek Olšák
Cc: Edmondo Tommasina
Cc: Nicolai Hähnle
---
src/m
On Wed, Nov 02, 2016 at 12:14:32PM +0900, Michel Dänzer wrote:
> On 01/11/16 08:10 PM, Chris Wilson wrote:
> > glXSwapBuffers() is translated internally into glXSwapBuffersMsc() with
> > a target and divisor of 0.
> >
> > https://www.opengl.org/registry/spe
On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
> On 22/10/16 07:00 PM, Chris Wilson wrote:
> > This applies a synchronisation point to GetBuffers() such that binding a
> > texture-from-pixmap its rendering is serialised with X. This matches the
> > synchronisat
On Wed, Nov 02, 2016 at 04:16:55PM +0900, Michel Dänzer wrote:
> On 02/11/16 04:13 PM, Chris Wilson wrote:
> > On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
> >> On 22/10/16 07:00 PM, Chris Wilson wrote:
> >>> This applies a synchronisation point to
p;(*bbo)->relocs,
> + cmd_buffer->device, &(*bbo)->bo);
> + }
> +
> + for (uint32_t i = 0; i < cmd_buffer->execbuf2.bo_count; i++) {
> + struct anv_bo *bo = cmd_buffer->execbuf2.bos[i];
> +
> + cmd_buffer->execbuf2.objects[i].offset = bo->offset;
/* bo->offset = last execobj.offset */
*reloc.offset = bo->offset + delta;
reloc.presumed_offset = bo->offset;
execobj.offset = bo->offset;
Looks good.
-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
*/
> + for (size_t i = 0; i < cmd_buffer->surface_relocs.num_relocs; i++)
> + cmd_buffer->surface_relocs.relocs[i].presumed_offset = -1;
> + }
>
> - return anv_device_execbuf(device, &cmd_buffer->execbuf2.execbuf,
> - cmd
if (time_elapsed > timeout) {
> + pthread_mutex_unlock(&device->mutex);
> + return VK_TIMEOUT;
> +}
> +
> +timeout -= time_elapsed;
Adjusts the bool and not the int64_t nanosecond counter.
Looks
On Thu, Nov 03, 2016 at 02:19:01PM -0700, Jason Ekstrand wrote:
>On Thu, Nov 3, 2016 at 1:53 AM, Chris Wilson <[1]ch...@chris-wilson.co.uk>
>wrote:
>
> Something to consider is just randomly assigning an address and using
> it. The kernel will relocate i
On Thu, Nov 03, 2016 at 09:07:55PM -0700, Jason Ekstrand wrote:
>On Thu, Nov 3, 2016 at 3:00 PM, Chris Wilson <[1]ch...@chris-wilson.co.uk>
>wrote:
>
> As it stands today, using NO_RELOC without PINNED, the kernel will
> arbitrarily assign an address to eac
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
Now that we also have to consider OES_viewport_array & friends, nothing uses
this.
Signed-off-by: Chris Forbes
---
src/mesa/main/get.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 5f5e76a..854f8ab 100644
--- a/src/mesa/main/get.c
+++ b
The mesa default is 4, but we program the hardware for 8 on all
generations.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index
t refuses to do relocations on an active buffer. Doing
> them in userspace and passing the NO_RELOC flag to the kernel allows us to
> perform the relocations without stalling.
>
> This improves the performance of Dota 2 by around 30% on a Sky Lake GT2.
>
> v2 (Jason Ekstrand):
&
here are no further
> objections.
From my pov, the use of and comments for execbuf2 NO_RELOC makes sense.
-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
ke the assembler and disassembler, and aubdump).
> Should this one move too? Do we have buy-in from Chris?
Sure, if it means that we do get an actively maintained decoder - just
hope that gen2-3 is forthcoming, and perhaps some inferred type
decoding.
What's more important is that it is fa
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
On Tue, Apr 04, 2017 at 05:09:53PM -0700, Kenneth Graunke wrote:
> Using an incoherent CPU map on the active scanout buffer is really
> sketchy - we may need extra flushing via GEM_SW_FINISH, or using
> drmModeDirtyFB() and kernel commit a6a7cc4b7db6d (4.10+).
>
> Chris suggests
>
> 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
On Tue, Apr 04, 2017 at 05:10:06PM -0700, Kenneth Graunke wrote:
Replace the duplicated macros imported from libdrm:
ARRAY_SIZE, MAX2, ALIGN
and remove the unused one. Hmm, I think the remove should perhaps be the
previous patch where it's last user was removed.
Reviewed-by:
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 ---
and it makes no sense to have two has_llc flags
> set by different mechanisms.
Just remember the kernel query actually tells you something more than
what you know from just querying pci-id. As you replace the buffer cache
management, that will become more obvious (and directly controllable).
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
___
1 - 100 of 1254 matches
Mail list logo
