+0100
radeonsi/vcn: Return error when decoding 12bit VP9 and 4:2:2/4:4:4 AV1
Cheers,
Chris
---
...
Cheers,
Chris
hevc-vdpau.
[vd] Skipping previously attempted hwdec: hevc-vdpau
[vd] Using software decoding.
Does this look like another Mesa / VDPAU bug (i.e. should I raise a
new issue for it?), or is it actually a problem with mpv?
Cheers,
Chris
On Thu, 15 Feb 2024 at 16:01, Liu, Leo wrote:
>
> [
,
Chris
scores 588.
Anything help fix the bug is welcome.
Thanks
Chris
Hi, thanks for replying.
Yes, that simple patch seems to have done the trick.
Cheers,
Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
0,
5.10.5, LLVM 12.0.0)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.0.0-devel
(git-4292fb2139)
Cheers,
Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This is enforcing a hard requirement in the spec:
30.1. Feature Requirements
All Vulkan graphics implementations must support the following features:
* robustBufferAccess
On Fri, Nov 8, 2019 at 1:49 PM wrote:
>
> Testing my Vulkan driver agains Vulkan CTS, I am a bit suprised, that is
> seem
Quoting Eric Engestrom (2019-10-31 14:06:40)
> On Thursday, 2019-10-31 07:35:04 +0000, Chris Wilson wrote:
> > The system can be disabling HW acceleration unbeknowst to the user,
> > leading to a long debug session trying to work out which component is
> > failing. A quick m
The system can be disabling HW acceleration unbeknowst to the user,
leading to a long debug session trying to work out which component is
failing. A quick mention that it is the environment override would be
very useful.
---
src/egl/main/egldriver.c | 2 ++
1 file changed, 2 insertions(+)
diff --
Quoting Daniel Stone (2019-08-30 14:13:08)
> Hi,
>
> On Thu, 29 Aug 2019 at 21:35, Chris Wilson wrote:
> > Quoting Kristian Høgsberg (2019-08-29 21:20:12)
> > > On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson
> > > wrote:
> > > > Quoting Kenneth Gra
Quoting Kristian Høgsberg (2019-08-29 21:20:12)
> On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson
> wrote:
> >
> > Quoting Kenneth Graunke (2019-08-29 19:52:51)
> > > Some cons:
> > >
> > > - Moving bug reports between the kernel and Mesa would be harde
hat we move the kernel bugzilla along with it. Trying
to keep abreast of the bugs in the whole stack is important. Fwiw, the
kernel contains the https:bugs.freedesktop.org/enter_bug.cgi?product=DRI
URL so would need some redirection for a few years...
-Chris
_
Not all hardware is made equal and some does not have the full
complement of 48b of address space. Ask what the actual size of virtual
address space allocated for contexts, and bail if that is not enough to
satisfy our static partitioning needs.
Cc: Kenneth Graunke
---
src/gallium/drivers/iris/i
Quoting Jordan Justen (2019-03-31 10:57:09)
> On 2019-03-25 03:58:59, Chris Wilson wrote:
> > iris currently uses two distinct GEM contexts to have distinct logical
> > HW contexts for the compute and render pipelines. However, using two
> > distinct GEM contexts implies t
Quoting Jordan Justen (2019-03-31 10:53:06)
> Where are these changes from (repo/commit)? It could be good to
> reference in the commit message.
They don't exist in drm-next yet, so they don't have a reference.
-Chris
___
mesa-dev maili
Quoting Kenneth Graunke (2019-03-26 17:01:57)
> On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2019-03-26 05:52:10)
> > > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > > > iris currently uses two distinct
Quoting Kenneth Graunke (2019-03-26 05:52:10)
> On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > iris currently uses two distinct GEM contexts to have distinct logical
> > HW contexts for the compute and render pipelines. However, using two
> > distinct GEM
We want to opt out of the automatic GPU recovery and replay performed by
the kernel of a guilty context after a GPU reset as our incremental
batch construction very often implies that subsequent batches are a GPU
reset are incomplete and will trigger fresh GPU hangs. As we are aware
of how we need
For use in GPU recovery and pipeline construction.
---
include/drm-uapi/i915_drm.h | 389 +---
1 file changed, 317 insertions(+), 72 deletions(-)
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index d2792ab3640..59baacd265d 100644
--- a/incl
iris currently uses two distinct GEM contexts to have distinct logical
HW contexts for the compute and render pipelines. However, using two
distinct GEM contexts implies that they are distinct timelines, yet as
they are a single GL context that implies they belong to a single
timeline from the clie
Quoting Rafael Antognolli (2019-03-05 19:33:03)
> On Tue, Mar 05, 2019 at 09:40:20AM +0000, Chris Wilson wrote:
> > Not all commands support being preempted as they execute, and for those
> > make sure we at least check for being preempted before we start so as to
> > try and
Not all commands support being preempted as they execute, and for those
make sure we at least check for being preempted before we start so as to
try and minimise the latency of whomever is more important than
ourselves.
Cc: Jari Tahvanainen ,
Cc: Rafael Antognolli
Cc: Kenneth Graunke
---
Always
Not all commands support being preempted as they execute, and for those
make sure we at least check for being preempted before we start so as to
try and minimise the latency of whomever is more important than
ourselves.
Cc: Jari Tahvanainen ,
Cc: Rafael Antognolli
Cc: Kenneth Graunke
---
src/me
Quoting Emil Velikov (2019-02-28 11:44:28)
> On Tue, 26 Feb 2019 at 21:52, Chris Wilson wrote:
> >
> > A few of the GEM drivers provide matching ioctls to allow control of
> > their bo caches. Hook these up to APPLE_object_purgeable to allow
> > clients to discard
bustness pov, run through
with GL_UNDEFINED_APPLE in between, so the objects are discarded before
attempting to reuse (and gracefully failing).
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
A few of the GEM drivers provide matching ioctls to allow control of
their bo caches. Hook these up to APPLE_object_purgeable to allow
clients to discard video memory under pressure where they are able to
fallback to restoring content themselves, e.g. from their own (presumably
compressed, on disk)
A few of the GEM drivers provide matching ioctls to allow control of
their bo caches. Hook these up to APPLE_object_purgeable to allow
clients to discard video memory under pressure where they are able to
fallback to restoring content themselves, e.g. from their own (presumably
compressed, on disk)
Quoting Lionel Landwerlin (2019-02-21 12:57:09)
> I did not find the PRM bit that says it must be 64b aligned, but I can
> see that's what i915 checks.
>
> Chris: If you have a pointer to it, I could add the quote.
In amongst the register specs,
PLANE_STRIDE:
For Linear m
ff-by: Samuel Iglesias Gonsálvez
>
>
> That looks good to me :
> Reviewed-by: Lionel Landwerlin
>
> I'm doing a CI run just to convince myself, so if you can wait for that.
Is scanout a concern? The display engine also requires 64B alignment for
linear.
-Chris
To make wedging even more likely, we use a new "no recovery" context
parameter that tells the kernel to not even attempt to replay any
batches in flight against the default context image, as experience shows
the HW is not always robust enough to cope with the conflicting state.
This allows us to al
XXX Not in drm-next XXX
Pull i915_drm.h to include
commit ba4fda620a5f7db521aa9e0262cf49854c1b1d9c (HEAD -> drm-intel-next-queued,
drm-intel/drm-intel-next-queued)
Author: Chris Wilson
Date: Mon Feb 18 10:58:21 2019 +
drm/i915: Optionally disable automatic recovery after a GPU re
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to re
Introduce a new debug option to wilfully cause the GPU to hang and for
the kernel to accuse of being neglectful.
---
src/intel/Makefile.sources| 2 +
src/intel/common/gen_debug.c | 1 +
src/intel/common/gen_debug.h | 1 +
src/intel/common
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to re
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to re
Object handles are local to the device fd, so double check we are not
mixing together objects from multiple screens on execbuf submission.
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_b
Quoting Chris Wilson (2019-02-14 12:05:00)
> If we hang the GPU and end up banning our context, we will no longer be
> able to submit and abort with an error (exit(1) no less). As we submit
> minimal incremental batches that rely on the logical context state of
> previous batches, we
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to re
state that isn't being reset (since BRW_NEW_CONTEXT went out of fashion
;) I'd like to get this concept acked so that we can land the
corresponding kernel patch and make the uAPI official and start putting
it to use.
-Chris
___
mesa-dev m
Object handles are local to the device fd, so double check we are not
mixing together objects from multiple screens on execbuf submission.
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_b
Quoting Kenneth Graunke (2019-01-08 20:17:01)
> On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > Hi Andrii,
> > >
> > > Although I think what these patches do makes sense, I think it
Quoting andrey simiklit (2019-01-08 16:00:45)
> On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's mi
nd just
demand the kernel provide logical contexts for all i965 devices (just ack
some patches!), and then just flush the batch (possibly with a dummy 3D
prim if you want to be sure the 3D state is loaded) and rely on the
context preserving state across batches.
-Chris
Quoting Chris Wilson (2018-10-24 09:40:08)
> If we hang the GPU and end up banning our context, we will no longer be
> able to submit and abort with an error (exit(1) no less). As we submit
> minimal incremental batches that rely on the logical context state of
> previous batches, we
Quoting Mathias Fröhlich (2018-11-23 17:14:45)
> Hi Chris,
>
> On Friday, 23 November 2018 16:12:38 CET Chris Wilson wrote:
> >
> > Something to note here is that valgrind reports
> > (piglit/bin/drawoverhead):
> >
> > ==492== Use of uninitialised valu
t_draw.c:149)
==492==by 0x70F5BF4: _mesa_validated_drawrangeelements (draw.c:850)
==492==by 0x70F5BF4: _mesa_validated_drawrangeelements (draw.c:782)
==492==by 0x70F5F32: _mesa_DrawElements (draw.c:1004)
==492==by 0x48F6C74: stub_glDrawElements (piglit-dispatch-gen.c:12618)
==492==by 0x10B3F4: draw (drawoverhead.c:275)
==492==by 0x10D070: perf_measure_rate (common.c:56)
==492==by 0x10C69E: perf_run (drawoverhead.c:645)
==492== Uninitialised value was created by a stack allocation
==492==at 0x714C25D: st_update_array (st_atom_array.c:389)
from velements being used sparsely.
Does your patch prevent this?
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
rw, true);
To force the LRI despite what the context may believe. (To accommodate
recreating a logical context following a GPU hang.)
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to re
ually put that in the project under docs.
> Maybe it helps other people as well?
May I suggest spdx.org and in particular using a format such as
/* SPDX: MIT */
with a toplevel description of what the link means. From a dev point of
view, it's much quicker to
Quoting Ian Romanick (2018-10-10 00:24:00)
> On 10/09/2018 06:24 AM, Chris Wilson wrote:
> > The userspace driver does not exist in isolation and occasionally
> > depends on kernel uapi, and so it is useful in bug reports to include
> > that information. (radeonsi, r600 and
The userspace driver does not exist in isolation and occasionally
depends on kernel uapi, and so it is useful in bug reports to include
that information. (radeonsi, r600 and radv already include utsname)
References: https://bugs.freedesktop.org/show_bug.cgi?id=108282
---
src/mesa/drivers/dri/comm
Quoting Kenneth Graunke (2018-10-06 02:57:29)
> On Tuesday, October 2, 2018 11:06:23 AM PDT Chris Wilson wrote:
> > Reuse the same query object buffer for multiple queries within the same
> > batch.
> >
> > A task for the future is propagating the GL_NO_MEMORY err
If we map the bo upon creation, we can avoid the latency of mmapping it
when querying, and later use the asynchronous, persistent map of the
predicate to do a quick query.
v2: Inline the wait on results; it disappears shortly in the next few
patches.
Signed-off-by: Chris Wilson
Cc: Kenneth
using the last known flag, the query is split into two.
v2: Check against external bo before trusting our own tracking.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 40 --
src/mesa/drivers/dri/i965
ioctl, the busy-ioctl is lightweight!).
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_context.h | 4 +-
src/mesa/drivers/dri/i965/gen6_queryobj.c | 54 ++-
2 files changed, 25 insertions(+), 33 deletions(-)
diff --git
Skip the next check for brw_batch_references() by recording when we
flush the query.
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
b/src/mesa/drivers/dri/i965/gen6_queryobj.c
i
Reuse the same query object buffer for multiple queries within the same
batch.
A task for the future is propagating the GL_NO_MEMORY errors.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_context.c | 3 ++
src/mesa/drivers/dri/i965
Be consistent in passing along brw_context rather than switching between
that and gl_context.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 30 +++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
To simplify replacement later, replace repeated use of explicit 0/1 with
local variables of the same value.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 30 ---
1 file changed, 16 insertions(+), 14
(where the results are used directly by the GPU and not
CPU).
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_bufmgr.c| 24 +++
src/mesa/drivers/dri/i965/brw_bufmgr.h| 2 ++
src/mesa/drivers/dri/i965/gen6_queryobj.c
Lots of places open-coded the assumed layout of the predicate/results
within the query object, replace those with simple helpers.
v2: Fix function decl style.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
.../drivers/dri/i965/brw_conditional_render.c | 10
nt is
the empty batch, we will just repeat ourselves.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
As a prelude to handling large address spaces, first allow ourselves the
luxury of handling the full 4G.
Reported-by: Andrey Simiklit
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 9 +
src/mesa/drivers/dri/i
t; > - if (brw) {
> > - perf_debug("Fallback GTT mapping for %s with access flags %x\n",
> > -bo->name, flags);
> > - }
> > - map = brw_bo_map_gtt(brw, bo, flags);
> > - }
> > -
> > return map;
&g
unnecessary.
>
> v2: Add some explanation (Chris/Lionel)
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.c | 34 --
> 1 file changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/
ufmgr = bo->bufmgr;
>
/* Please do explain why :)
*
* We have been doing a good job explaining the intricacies with both
* the kernel and hw interfaces, so keep up the good work!
*
* I do think it is worth mentioning the incoherency issue, so that if
* anybody ever suggests GTT mmaps are a goo
even need this patch.
> The code is confusing though.
Still document that you don't :-p
So reduce it to an assert?
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Quoting Lionel Landwerlin (2018-08-31 12:32:23)
> On 31/08/2018 12:22, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-08-31 12:16:19)
> >> We would need a fairly recent kernel (drm-tip?) to test this in CI.
> > Unpatched mesa, assumes all is fine.
> > P
ly leaks through to glMapBufferRange with
say GL_MAP_PERSISTENT_BIT. Hmm, maybe that's all ok so long at the
client flushes are explicit.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On more recent HW, the indirect writes via the GGTT are internally
buffered presenting a nuisance to trying to use them for persistent
client maps. (We cannot guarantee that any write by the client will
then be visible to either the GPU or third parties in a timely manner,
leading to corruption.) F
L_OFFSET_FIX_ENABLE (1 << 1)
> +# define TEXEL_OFFSET_FIX_MASK REG_MASK(1 << 7)
That mask doesn't match the enable-bit.
It'll probably be quite useful to record all the registers you are
setting as part of the global setup and read them back later to m
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
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
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
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/18.3.0.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html
in
Quoting Michal Srb (2018-08-15 09:22:19)
> Hi,
>
> This is my first attempt to review patch for Mesa, so please take it with a
> grain of salt.
>
> On úterý 14. srpna 2018 20:21:40 CEST Chris Wilson wrote:
> > @@ -504,6 +506,24 @@ bo_alloc_internal(struct brw_bufmgr *b
allocations, while in the mean time making sure that
we do not waste any extra pages on them.
Signed-off-by: Chris Wilson
Cc: Sergii Romantsov
Cc: Lionel Landwerlin
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 24
1 file changed, 24 insertions
Quoting Lionel Landwerlin (2018-07-30 17:08:47)
> On 30/07/18 16:45, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-07-30 16:28:37)
> >> Gen10+ has an additional bit in MI_BATCH_BUFFER_END to signal the end
> >> of the context image.
> > Hmm, do you think
Quoting Lionel Landwerlin (2018-07-30 16:28:37)
> Gen10+ has an additional bit in MI_BATCH_BUFFER_END to signal the end
> of the context image.
Hmm, do you think we should perhaps include the BBE in the protocontext
we create in the kernel?
Reviewed-by: Chris Healy
On Mon, Jul 30, 2018 at 12:44 AM, Christian Gmeiner
wrote:
> Fixes: d0bed0b4944d ("etnaviv: support HI performance counters")
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnav
Quoting Sergii Romantsov (2018-07-25 10:37:29)
> Hello, Chris.
> Your variant also works.
> But i wonder about comment:
> /* If we don't have caching at this size, don't actually round the
> * allocation up.
> */
> if (bucket == NULL) {
>
>
Quoting Sergii Romantsov (2018-07-25 08:42:55)
> Hello,
> here is a backtrace:
...
Please try:
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e30ecc..8274c2e0b2f 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri
Quoting Lionel Landwerlin (2018-07-24 13:45:18)
> On 24/07/18 13:42, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-07-24 13:34:57)
> >> That looks correct to me (and we do the same in Anv).
> >> Also a bit baffled that we haven't run into issues earlier :
ng down who doesn't think
IS_ALIGNED(bo->size, PAGE_SIZE) would be interesting.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
it() for details on the 32k pitch limit.
> +*/
> + if (mt->surf.row_pitch >= 32768)
>return false;
I see the difference, but do we copy the whole slice or a region of it?
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
tx_id = ctx_id,
> + .load_type = load_type,
> + };
> + int err;
> +
> + err = 0;
> + if(drmIoctl(bufmgr->fd, DRM_IOCTL_I915_LOAD_TYPE, &type))
> + err = -errno;
This went through 4 people and none noticed that t
info, we see that non-linear tilings have
> widths greater than or equal to 128B.
Yup, we only have non-linear at this point and pitch has to a multiple
of tiles.
> Cc:
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.fre
Quoting Nanley Chery (2018-07-12 18:28:16)
> Retile miptrees to a linear tiling less often. Retiling can cause issues
> with imported BOs.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106738
> Suggested-by: Chris Wilson
> Cc:
Reviewed-by: Ch
Quoting Nanley Chery (2018-07-12 18:28:14)
> We'd like to reuse this helper.
>
> Cc:
Reviewed-by: Chris Wilson
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Stefan,
On 25 June 2018 at 18:09, Stefan Schake wrote:
> Hey Chris,
>
> On Fri, Jun 22, 2018 at 12:09 PM, chris simmonds
> wrote:
> > Hi.
> >
> > I would like to try out drm_hwcomposer on a RPi 3. Can anyone point me
> to a
> > howto or something that
Hi.
I would like to try out drm_hwcomposer on a RPi 3. Can anyone point me to a
howto or something that tells me how?
FYI, this is part of a side project to port drm_hwcomposer to BeagleBones
and other things based on TI SoCs
Thanks,
Chris Simmonds
+++
> src/util/rb_tree.h| 269
No tester? Insert/remove 1,000,000 u32 and check the post-order is sorted
and has correct coloring? (I'm stealing ideas from
kernel/lib/rbtree_test.c fwiw.)
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Quoting Chris Wilson (2018-06-18 11:10:23)
> We should we have all the kinks worked out and full-ppgtt now works
> reliably on gen7 (Ivybridge, Valleyview/Baytrail and Haswell). If we can
> let userspace have full control over their own ppgtt, it makes softpinning
> far more effect
We believe we have all the kinks worked out, even for the early
Valleyview devices, for whom we currently disable all ppgtt.
References: 62942ed7279d ("drm/i915/vlv: disable PPGTT on early revs v3")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Joonas Lahtinen
Reviewed-by: Joona
(due to better mm segregation). On the other hand, switching
over to a different GTT for every client does incur noticeable overhead.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
Reviewed-by: Joonas Lahtinen
Cc: Jason Ekstrand
Cc: Kenneth Graunke
Quoting Nanley Chery (2018-06-14 19:46:09)
> On Thu, Jun 14, 2018 at 10:01:18AM -0700, Nanley Chery wrote:
> > On Thu, Jun 14, 2018 at 04:18:30PM +0300, Martin Peres wrote:
> > > This fixes screenshots using 8k+ wide display setups in modesetting.
> > >
> > &g
> + void *map;
> + uint64_t address;
> + uint32_t size;
Why is size only 32b? I didn't see where large bo would be split into
multiple chunks.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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/18.2.0.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/relnotes/18.2.0.html b/docs/relnotes/18.2.0.html
in
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
1 - 100 of 2440 matches
Mail list logo
