rom 584 years to 292 years - likely not a big deal.
>
> which doesn't make sense. If we feel like we need to point out that
> we've fixed the bug, that's fine, but keep the part about how some
> kernels are broken so it's clear why the workaround is needed.
That fi
use of it and in the process fix my reversed
> > detection of the buggy reads for unpatched kernels.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Martin Peres
> > Cc: Kenneth Graunke
> > Cc: Michał Winiarski
> > Cc: Daniel Vetter
> > ---
> >
>>
> >
> > Sure, attached is the hang I get if I don't set the restriction in
> > gen8_misc_state.c and try to use the full 48-bit range
> > (i915_error_state_nowa.txt). This is just running gfxbench t-rex.
> >
> > I see the same hang signature when it is only applied to the scratch bos (in
> > gen8_vs_state.c, gen8_gs_state.c and gen8_ps_state.c -
> > i915_error_state_scratchbo.txt).
> >
> > 3DSTATE_VIEWPORT_STATE_POINTERS_CC (0x7823) is defined here:
> > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-bdw-vol02a-commandreference-instructions_0.pdf
> > (page 256)
>
> I applied your mesa and libdrm patches and then backed out the 4G
> restriction in the STATE_BASE_ADDRESS relocations. I was not able to
> reproduce any hang with trex or glxgears. I confirmed (using
> INTEL_DEBUG=bat) that gem actually placed BOs above the 4G mark and
> got this:
>
> 0: 8 @ 0xfff9 (miptree)
> 1: 9 @ 0xfff78000 (hiz)
> 2: 4 @ 0xfff77000 (pipe_control workaround)
> 3: 5 @ 0xfff76000 (program cache)
> 4: 12 @ 0x (miptree)
> 5: 7 @ 0x1000 (image)
> 6: 10 @ 0xfff5a000 (miptree)
> 7: 13 @ 0xfff59000 (bufferobj)
> 8: 11 @ 0xfff51000 (bufferobj)
> 9: 14 @ 0xfff5 (bufferobj)
> 10: 15 @ 0xfff4 (batchbuffer)@0x 0020 -> 8
> (miptree)@0x fff9 + 0x
> 10: 15 @ 0xfff4 (batchbuffer)@0x 0040 -> 9
> (hiz)@0x fff78000 + 0x
> 10: 15 @ 0xfff4 (batchbuffer)@0x 0098 -> 4
> (pipe_control workaround)@0x fff77000 + 0x
> ...
>
> In particular, the mesa batchbuffer is placed at 0xfff4, and
> all the STATE_BASE_ADDRESS heaps are in that bo. In other words, all
> heap bases are set to 0xfff4.
>
> The offset in 3DSTATE_VIEWPORT_STATE_POINTERS_CC is indeed only 32
> bits, but that only affects how far from the dynamic state base
> address we can place that. In mesas case, it's always inside the batch
> buffer, which is at most 32k, so that's never a problem. If a driver
> uses dynamic state in a heapless fashion, then you need to be careful
> to place the CC viewport state below 4g.
>
> What I was able to confirm is that scratch buffer I/O (which we use
> for spilling) does break with 48 bit ppgtt. If you run glxgears with
> INTEL_DEBUG=spill_fs set, you can see lots of rendering artifacts as
> the 4G limit on the general state heap caps attempts to spill and fill
> from the vertex shader. Using OUT_RELOC64_INSIDE_4G() when setting up
> the scratch BOs in 3DSTATE_VS and 3DSTATE_PS fixes the problem.
Ok, so we do still need the 4G limit bit (i.e. I don't have to revert the
kernel side for lack of open-source userspace), just not at the place we
originally thought. I guess lesson learned is to actually test stuff first
before I pull in the kernel side. Michel, did you not see the spilling
corruptions when testing the mesa patches? Kristian, does this also blow
up with just a piglit run?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
about that.
Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.
Thanks,
Daniel, secretary of the board
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffw
onstant GTT size as it also computes addition information not
> used here and has the side-effect of doing a sysfs scan for PCI
> devices.)
>
> Signed-off-by: Chris Wilson
Since I just pulled in the kernel side earlier today:
Reviewed-by: Daniel Vetter
> Cc: Daniel Vetter
>
tion to make informed calls about when to throttle and how.
So is there no gl entry point in mesa we can abuse and make this happen?
Citing the spec doesn't make the real world issue go away.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ff
temp_bo, upload,
> size);
> -
> brw_bo_put(temp_bo);
> return;
>} else {
> --
> 2.5.0
>
> _______
> mesa-dev mailin
+++
> lib/sw_sync.h | 49
> tests/Makefile.sources | 1 +
> tests/sw_sync.c| 693
> +
> 5 files changed, 982 insertions(+)
> create mode 100644 lib/sw_sync.c
> create mode 100644 lib/sw_sync.h
> c
On Wed, Aug 24, 2016 at 04:41:02PM -0400, Gustavo Padovan wrote:
> 2016-08-24 Daniel Vetter :
>
> > On Tue, Aug 23, 2016 at 01:56:02PM -0400, robert.f...@collabora.com wrote:
> > > From: Robert Foss
> > >
> > > This series implements the sw_sync test and
915_PARAM_MMAP_GTT_VERSION:
> + /* 0 - Objects have to be smaller than aperture,
> + * all simultaneous users have to fit within the
> + * available space within the aperture.
> + * 1 - Objec
the mappable aperture.
>
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
Reviewed-by: Daniel Vetter
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 17 ++---
> src/mesa/drivers/dri/i965/brw_context.h | 2 +-
> src/mesa/dri
7;m not really sure what I'd suggest, to be honest. It seems like a
> > lot of aggravation for a minimal reward if done right.
> >
> > [1] https://lists.freedesktop.org/archives/mesa-dev/2015-August/090972.html
> > [2] https://lists.freedesktop.org/archives/mesa-dev/2015-August/090984.html
> > ___
arguably the feature
> it exposes currently provides broken counter data without Rob's work.
> But the others...you're not going to remove.
>
> If you start taking away features, the version getparam is entirely
> meaningless. We can't infer anything from it, an
ed by default on
> all kernel versions exposing cmd_parser_version >= 2? Wouldn't this
> break things if the command parser is disabled in the kernel command
> line? [Currently it would just cause some extensions to be disabled]
We have the stance that touching an
On Sat, Nov 12, 2016 at 3:01 PM, Rob Clark wrote:
> On Sat, Nov 12, 2016 at 8:30 AM, Daniel Vetter wrote:
>> On Fri, Nov 11, 2016 at 05:57:54PM +0100, Wladimir J. van der Laan wrote:
>>> Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the
>>> comm
reenode) tends to be much faster, since you can follow up
right away.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
B8G8R8A8_UNORM;
>break;
> + case MESA_FORMAT_Z32_FLOAT:
> + this->brw_surfaceformat = BRW_SURFACEFORMAT_R32_FLOAT;
> + break;
> case MESA_FORMAT_Z16:
>this->brw_surfaceformat = BRW_SURFACEFORMAT_R16_UNORM;
>break;
> --
&g
t or so might be good.
Otherwise I've had plenty fun reading around in blorp and the format
tables, so fwiw (and hey, it's very little!)
Reviewed-by: Daniel Vetter
It's a bit hairy how the outermost blt code needs to check the depth
stuff, I'd have prefered to keep that logi
n the write_reg
helper used by the gen6 queryobj code.
Cc: Kenneth Graunke
Signed-off-by: Daniel Vetter
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
b/src/mesa/drivers/dri/i965/gen6_q
apps. So imo this should go to stable, but maybe
after an extended soaking time.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
ed through any libdrm function afaics.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 07, 2013 at 04:23:12PM -0800, Ian Romanick wrote:
> On 11/07/2013 01:33 PM, Daniel Vetter wrote:
> > On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick wrote:
> >> + /* Once a batch uses more than 75% of the maximum mappable size, we
> >> +
> + .base = { __DRI2_RENDERER_QUERY, 1 },
> +
> + .queryInteger = i915_query_renderer_integer,
> + .queryString = i915_query_renderer_string
> +};
> +
> static const __DRIextension *intelScreenExtensions[] = {
> &intelTexBufferExtension.base,
> &a
On Mon, Nov 11, 2013 at 11:03:49AM -0800, Ian Romanick wrote:
> On 11/09/2013 02:44 AM, Daniel Vetter wrote:
> > On Fri, Oct 11, 2013 at 03:10:14PM -0700, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> Signed-off-by: Ian Romanick
> >> ---
&
t; Signed-off-by: Ian Romanick
> Cc: Daniel Vetter
> Cc: "10.0"
> ---
> src/mesa/drivers/dri/i965/intel_screen.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/
On Mon, Nov 11, 2013 at 01:45:43PM -0800, Ian Romanick wrote:
> On 11/11/2013 01:35 PM, Daniel Vetter wrote:
> > On Mon, Nov 11, 2013 at 11:19:07AM -0800, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> Systems with little physical memory installed will
nter stuff with the CS checker.
- What about OA users on other rings? Iirc that stuff might be useful for
opencl running on the VCS ring, too. Otoh we don't have that need right
now, and the kernel could always just pass an OA token between rings and
synchronize with semaphores. Without the
B, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
>
> + { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
> +
> { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
> { { 0, 0
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> Hm, where do we have the canonical source for all these fourcc codes? I'm
>> asking since we have our own copy in the kernel as drm_fourcc.h, and that
>> one is part of the userspac
treats it as cached. Effect should be the
same cacheline dirts, and they can happen even if mesa _never_ access the
bo from the gpu with cached mocs settings or with the cpu.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
__
e entire cache
and checks for other reaped buffer objects.
With this you don't need tunables like the 1s delay you're using and
instead cache size is directly driven by vm pressure.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.
ing
> the pixel format to gbm so we can generate buffers with that format.
Creating 10bpc rgb framebuffers also works with the old addfb ioctl, same
for rbg565 and rgb555. Heck even c8 palette mode works ;-) Just so you
don't unduly restrict the wayland/weston support here ...
Cheers,
else {
>intel_miptree_map_gtt(intel, mt, map, level, slice);
> }
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
+ intel_miptree_map_blit(intel, mt, map, level, slice);
> } else {
>intel_miptree_map_gtt(intel, mt, map, level, slice);
> }
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
>
your other comments, we need to have a proper interface for
userspace to figure this out. And snoopable bos obviously need a separate
cache, otherwise we'll drown in clflush. On the patch:
Reviewed-by: Daniel Vetter
> ---
> src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 23 ++
e the check for zero fences available, but that doesn't
> seem worth checking.
Iirc this can only happen when we have ums and the ddx wants more fences
than it should ask for. Ums is long gone, too. Last two patches are
Reviewed-by: Daniel Vetter
Aside: We have a bit an accounting bug here
5_TILING_Y;
>
> if (width0 >= 64)
> - return I915_TILING_X;
> + return intel->gen >= 6 ? I915_TILING_Y : I915_TILING_X;
>
> return I915_TILING_NONE;
> }
> --
> 1.8.1.1
>
> ___________
> mesa-dev mailin
On Tue, Apr 09, 2013 at 01:17:39AM +0200, Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 07:27:38PM -0700, Kenneth Graunke wrote:
> > In the past, we preferred X-tiling for color buffers because our BLT
> > code couldn't handle Y-tiling. However, the BLT paths have been lar
things up to keep gen2
working. So maybe mesa should start shipping with a i830_dri.so ->
i915_dri.so symlink and the ddx should start to ask for the i830 dri on
gen2.
Back in the days when I didn't just have little, but provable zero clue
I've had some amusement around that on my
expect that someone will make a funny collision between
all the different projects anyway, so meh.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
get_tiling.handle = bo_gem->gem_handle;
> @@ -3301,5 +3319,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
> DRMINITLISTHEAD(&bufmgr_gem->vma_cache);
> bufmgr_gem->vma_max = -1; /* unlimited by default */
>
> + DRMINITLISTHEAD(&bufmgr_gem->prime);
> +
> return &buf
etime issues
around reference loops and some assorted locking fun) I'm not volunteering
to fix this ;-) And I also think that a piece of userspace which both
flink-opens and prime imports on the same buffer gets both pieces.
Otoh this can't hurt either, so if you want to stick with this
sert (i.e. BUG_ON and friends) already with
the relevant no_return/unreachable stuff. So it'd do exactly what
Fransisco suggested: You get the debug assert but also no false positive
compiler warnings, even in release builds.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+4
4);
> --
> 1.8.4.4
>
> ___________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffw
the pipe_control i-g-t testcase (and
that one checks whether the write lands) for gen6&7, this is
Reviewed-by: Daniel Vetter
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965
rites with PIPE_CONTROL (and MI_FLUSH_DW, too) have a
stern w/a notice on all gen6+ generations that bit5 of the target address
must be cleared. I haven't checked existing users, but these here seem
safe. So
Reviewed-by: Daniel Vetter
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffe
7;ve lost this fight already ...
-Daniel
> +
> #define ADVANCE_BATCH() intel_batchbuffer_advance(brw);
> #define CACHED_BATCH() intel_batchbuffer_cached_advance(brw);
>
> --
> 1.8.4.4
>
> _______
> mesa-dev mailing list
> mesa-d
On Fri, Dec 13, 2013 at 10:04:53AM -0800, Kenneth Graunke wrote:
> On 12/13/2013 09:28 AM, Daniel Vetter wrote:
> > On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
> >> Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
> >> and the
rable buses. And due to abi
guarantees those drm driver names will stay the same forever.
Also there's the entire drmOpenByBusid stuff which gives you at least
something reasonable for pci devices (not anywhere else though), so we
could do that dance in reverse if we want to have a pci id based
lo
On Mon, Dec 16, 2013 at 11:19:56AM -0800, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Sat, Dec 14, 2013 at 3:33 AM, Kenneth Graunke
> > wrote:
> >> On 11/18/2013 12:58 PM, Emil Velikov wrote:
> >>> On 18/11/13 01:08, Keith Packard wrote:
>
and bdw. There's also a
module option to override that default.
If the write actually matters you need to consult the
I915_PARAM_HAS_ALIASING_PPGTT driver param. If it is set then you should
use ppgtt as the address space selector. This will even hold for full
ppgtt (so a better name would be USES_PPGTT_FOR_EXECBUF, but abi and all
that).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
nterface, I think the NAK is very well justified. At least for the
> API in its current form.
Aside for this discussion: All the tablet/phone/whatever you want to call
them SoCs intel ships (since there are also hsw SoCs now out there making
this complicated) Intel gfx is non coherent.
We
aiting,
> and I honestly have no idea when they're going to finish it.
>
> In the meantime, you can apply the attached patch to your kernel tree to
> disable the hardware scanner, letting you run whatever commands you want.
> Obviously, we can't ship this on production
sense for X-tiled and dword-size pixels, so shouldn't
we move this around a bit and keep a break of 256b for X-tiled and 64b
when Y-tiling is possible?
Otoh only pre-gen6 would care, so meh. Either way
Reviewed-by: Daniel Vetter
>
> - if (ALIGN(mt->total_width * mt->cpp, 512)
ufPlaneOffsets[i].Value;
> + }
> +
> + dri_image =
> + dri2_dpy->image->createImageFromFds(dri2_dpy->dri_screen,
> + attrs.Width, attrs.Height, attrs.DMABufFourCC.Value,
> + fds, num_fds, pitches, offsets,
> + attrs.DMABufYuvColorSpaceHint.Value,
> + attrs.DMABufSampleRangeHint.Value,
> + attrs.DMABufChromaHorizontalSiting.Value,
> + attrs.DMABufChromaVerticalSiting.Value,
> + NULL);
> +
> + return dri2_create_image(disp, dri_image);
> +}
> +
> #ifdef HAVE_WAYLAND_PLATFORM
>
> /* This structure describes how a wl_buffer maps to one or more
> @@ -1364,6 +1600,8 @@ dri2_create_image_khr(_EGLDriver *drv, _EGLDisplay
> *disp,
> case EGL_WAYLAND_BUFFER_WL:
>return dri2_create_image_wayland_wl_buffer(disp, ctx, buffer,
> attr_list);
> #endif
> + case EGL_LINUX_DMA_BUF_EXT:
> + return dri2_create_image_dma_buf(disp, ctx, buffer, attr_list);
> default:
>_eglError(EGL_BAD_PARAMETER, "dri2_create_image_khr");
>return EGL_NO_IMAGE_KHR;
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
est hangs? I'll borrow a Haswell
> > tomorrow and take a look at Piglit.
>
> No, it didn't seem to be any particular test. It would typically
> happen 10 or so tests into a piglit run, but didn't seem to correspond
> to anything specifically. I also noticed that loa
the first release that has the fix as it doesn't
> >seem to work on older versions either. At least in my case I get what
> >looks like the same issue when prime support enabled when running
> >kernel version 3.5.
>
> Your distro probably picked up
ing for dma_buf backed egl_image" we could
make the copying somewhat more explicit with something like the egl
streams stuff. I haven't read the spec for that closely yet, but
having a solid zero-copy guarantee with making copying explicit sounds
good to me. Also, to better cope with intero
gets tagged and
pushed to the real stable branch.
Also a nice service from the stable kernel guys is that they'll send you a
nag mail to submit a manual backport if the patch fails to apply cleanly
(or breaks the build somehow).
This way you can aggressively tag patches for backporting, ther
. Section 5.1.1 of the gen4
> -* bspec ("Data Cache") says that the data cache does not exist as
> -* a separate cache and is just the sampler cache.
> -*/
> drm_intel_bo_emit_reloc(brw->batch.bo,
> *out_offset + 4,
>
anyone cares we could add a debugfs
interface (or finally get real approval for the performance counters
the hw has an expose them properly). Not a intel_gpu_top user myself
though.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
__
onst.MaxCubeTextureLevels = 14; /* 8192 */
> + ctx->Const.MaxTextureMbytes = 1536;
Original gen4 (i.e. i965g) only has 512 MB of aperture ... Also going this
high runs the risk that you fool up with fragmentation, but meh.
You'd need to get at bufmgr_gem->gtt_size somehow. At least
MAT_T2U4 DRM_FORMAT_TUPLE(2, UINT, 4) /** (X,
> Y), 32-bit unsigned integer */
> +#define DRM_FORMAT_T4U4 DRM_FORMAT_TUPLE(4, UINT, 4) /** (X, Y,
> Z, W), 32-bit unsigned integer */
> +/**@}*/
> +
> +/** @name Floating-point values */
> +/**@{*/
> +#define DRM_FORMAT_T1F4 DR
On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
> Hi,
>
> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
> > On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauchesne wrote:
> >> This is a follow-up to:
> >> http://lists.freedesktop.org/archive
On Wed, Mar 19, 2014 at 7:30 AM, Gwenole Beauchesne wrote:
> 2014-03-15 12:28 GMT+01:00 Daniel Vetter :
>> On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
>>> Hi,
>>>
>>> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
>>> > O
turn I915_TILING_X;
>
> /* From the Ivy Bridge PRM, Vol4 Part1 2.12.2.1 (SURFACE_STATE for most
> --
> 2.1.3
>
> _______
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer
bug which
taints the kernel. Users really never should touch them (expect when we
ask them to for debugging), developers know what might happen. So fully
agreed that hurt feet aren't a concern here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.
his isn't cast in stone, but meant to reflect
reality and should be adjusted as needed.
v4: Fix typo.
Signed-off-by: Daniel Vetter
---
Hi all,
I discussed this a bit with a few people over the past few months (I
think), to get a feel for where the consensus might be. Goal here isn't
anyt
On Thu, Feb 14, 2019 at 10:00:17AM +0100, Daniel Vetter wrote:
> Clear rules avoid arguing.
>
> I think it'd be good to have an equally solid list on the kms side.
> But kms is much more meant to be a standard, and the list of userspace
> projects we've accepted in the pa
[Shouldn't send mails before coffee kicks in, some things got lost below]
On Fri, Feb 15, 2019 at 10:20 AM Daniel Vetter wrote:
>
> On Thu, Feb 14, 2019 at 05:47:06PM -0500, Rob Clark wrote:
> > On Thu, Feb 14, 2019 at 4:00 AM Daniel Vetter
> > wrote:
> > >
On Thu, Feb 14, 2019 at 05:47:06PM -0500, Rob Clark wrote:
> On Thu, Feb 14, 2019 at 4:00 AM Daniel Vetter wrote:
> >
> > Clear rules avoid arguing.
> >
> > I think it'd be good to have an equally solid list on the kms side.
> > But kms is much more m
On Tue, Apr 19, 2016 at 05:11:29PM -0400, Rob Clark wrote:
> From: Rob Clark
>
> Copied from linux kernel, with minimal changes to script (just to
> recognize mesa src tree rather than linux kernel src tree), and slimmed
> down MAINTAINER file syntax to recognize that we don't really have
> subsy
But I guess that can be changed once
that happens.
Aside: The kernel lacks a define for Ys right now, but that was simply an
oversight since mesa patches didn't exist back then yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
| 28 +
> > src/mesa/main/performance_monitor.c| 579 -
> > src/mesa/main/performance_monitor.h| 39 -
> > src/mesa/main/performance_query.c | 608 +
> > src/mesa/main/performance_query.h | 80 +
> > 16 files changed, 3197 insertions(+), 2197 deletions(-)
> > delete mode 100644 src/mesa/drivers/dri/i965/brw_performance_monitor.c
> > create mode 100644 src/mesa/drivers/dri/i965/brw_performance_query.c
> > create mode 100644 src/mesa/main/performance_query.c
> > create mode 100644 src/mesa/main/performance_query.h
> >
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
seful
> though, as drm_intel_bo_subdata/pwrite doesn't know that it's safe to
> let the CPU write the buffer even while the GPU is reading it.
We coul add a flag to the timeout ioctl (which works like busy for
timeout=0) asking to just wait for read-only access. Shouldn't be a
a/drivers/dri/i965/gen8_surface_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Cc'd to stable because it's a pretty trivial change and provides a sizable
> boost to performance on new hardware.
Both patches are Reviewed-by: Daniel Vetter
Aside: Not using
d need one to
indicate that the cmd parser actually does something useful. Probably best
done with just another bump. And if we do that we could replace the
current trick mesa uses with just a getparam query - the getparam is fixed
so either returns -EINVAL on old kernels or the cmd parser vers
ond version of
> the patch to do that. I will post a v2 of the kernel patch too.
Oh, I guess my earlier mail was too late. One issue still is picking the
numbers, since you seem to assume here that ver >= 2 means the stuff
actually works. But like Ken said the cmd parser in upstream isn&#x
ches from Brad if we detect libva
tricks we'll still let it pass, just not with elevated privs needed for
writing special registers. And the point of enabling the parser in 3.16
already was to have as much coverage early as possible to catch any
userspace issues we've missed.
-D
r batches.
>
> Signed-off-by: Kenneth Graunke
Yeah, kernel adds the CS stall bit both to the flush right before/after
the batch so this works. The kernel also has a comment so people hopefully
check userspace assumptions when testing this.
Reviewed-by: Daniel Vetter
Some useless bikesheds for you
tructure as well.
>
> Future IOCTLs should be more rigorously defined so that structures can
> be validated and IOCTLs rejected if output fields aren't set to zero.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Daniel Vetter
> ---
> src/gallium/winsys/sw/kms-dri/kms_dri_
On Wed, Mar 11, 2015 at 09:10:01AM -0700, Ian Romanick wrote:
> On 03/06/2015 06:30 AM, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:38:44PM -0800, Ian Romanick wrote:
> >> On 03/04/2015 10:28 AM, Chad Versace wrote:
> >>> That text does not appear in the GL
_t tiling;
> + if (intelScreen->devinfo->gen >= 9) {
> + tiling = I915_TILING_Y;
> + } else {
> + tiling = I915_TILING_X;
> + }
> unsigned long pitch;
> int cpp = format / 8;
> intelBuffer->bo = drm_intel_bo_alloc_tiled(intelScreen->b
posals - it
> allows greater flexibility as both drivers will be tightly coupled and
> can communicate directly, does not expand the internal/hidden ABI that
> we currently have between GBM and EGL, could (in theory) work with
> GLX.
I think composite driver makes sense if you e.g. have
fence + syncpt stuff is
> >> wired up through all the drivers?
> >
> > Synchronization is just one piece. Your also have to consider things like
> > alignment and format restrictions for video decode for example. These can be
> > different from 3d so you need som
On Tue, Mar 29, 2016 at 10:00:00AM -0400, Rob Clark wrote:
> On Tue, Mar 29, 2016 at 4:41 AM, Daniel Vetter wrote:
> > On Sat, Mar 26, 2016 at 07:44:58PM -0400, Rob Clark wrote:
> >> On Sat, Mar 26, 2016 at 7:09 PM, Stéphane Marchesin
> >> wrote:
> >> >
&
some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
me
SUBSLICE_TOTAL 33
> #define I915_PARAM_EU_TOTAL 34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN 37
>
> typedef struct drm_i915_getparam {
> int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
> #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
&g
On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruiling
&
ince the 48bit
specific thing proposed looks like a fairly short-lived stop-gap, and
since the current no-reloc we already have would work everywhere. And
yeah I've been poking people to look at this for years. too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson wrote:
> On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
>> On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson
>> wrote:
>> >> > > If a GPU
>> >> > > client uses only prelocations, the r
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson wrote:
> On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
>> On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson
>> wrote:
>> >> > > If a GPU
>> >> > > client uses only prelocations, the r
--- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> > +++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> > @@ -395,12 +395,7 @@ brw_map_buffer_range(struct gl_context *ctx,
> >length +
> >
->gpu_active_end <= offset) {
> > - if (brw->has_llc) {
> > - void *map = brw_bo_map_unsynchronized(brw, intel_obj->buffer);
> > - memcpy(map + offset, data, size);
> > - brw_bo_unmap(intel_obj->buffer);
> > + void
param uses (yet) the sign bit, reserve it for errors
> > */
> > +
> > + memset(&gp, 0, sizeof(gp));
> > + gp.param = name;
> > + gp.value = &v;
> > + if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp))
> > + return -1;
> > +
> &g
xactly the limit is, and userspace just can't
know. So maybe add:
* The killer on top is that some gen4 have an L-shaped swizzle
* mode, where parts of the memory aren't swizzled at all. Userspace
* just can't handle that.
Either way looks good, fwiw
Reviewed-by: D
numbers.
Doing partial reads through cpu mmaps on non-llc isn't going to be fast
due to the clflush stuff. But since the meta stuff as fallback doesn't do
any kind of blt copy (I dont know mesa enough to be sure, but that's my
assumption at least), this shouldn't hurt. It
h a min/max vrefresh
rate, or something similar.
Finally I'm not sure we want to insist on a target time for freesync. At
least as far as I understand things you just want "as soon as possible".
This might change with some of the VK/EGL/GLX extensions where you
specify a precise
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
> On 17/10/17 02:22 PM, Daniel Vetter wrote:
> > On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> >
> >>> Common sense sugges
On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote:
> On 17/10/17 05:04 PM, Daniel Vetter wrote:
>> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>>> On 17/10/17 02:22 PM, Daniel Vetter wrote:
>>>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel D
1 - 100 of 339 matches
Mail list logo
