Since not all memory ranges can be mapped by userptr, in particular those
passed by XShmAttachFD, we need to validate the userptr before use. We
would ideally want to continue to lazily populate the pages as often the
userptr is created but never used, but preventing an EFAULT later is
more important.
In https://patchwork.freedesktop.org/series/33449/ we provided a more
efficient method for probing the userptr on construction while
preserving the lazy population of gup-pages. For now, always follow
userptr with set-domain.
Reported-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since not just Haswell will enjoy clear-residuals, be very careful
before using a potential context switch from DRI clients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When there is ample memory bandwidth and we are not fighting for global
resources, enable TearFree by default. Avoiding tearing is much more
pleasant (for direct rendering where the source itself is not being
synchronized to vblank) at negligible power cost; just doubles the
memory footprint of scanout.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2799
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2763
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mike Lothian ran into a surprising situation where compScreenUpdate was
calling CompositePicture without a pixmap attached to the destination
Window, and so we found ourselves chasing a NULL PixmapPtr.
#1 to_sna_from_pixmap (pixmap=0x0) at sna.h:521
#2 sna_composite (op=<optimized out>, src=0x55b3346c1420, mask=0x0,
dst=0x55b3346c1d50, src_x=<optimized out>, src_y=<optimized out>, mask_x=0,
mask_y=0, dst_x=0, dst_y=0, width=3840, height=2160) at sna_composite.c:652
#3 0x000055b33202c208 in damageComposite (op=<optimized out>,
pSrc=0x55b3346c1420, pMask=0x0, pDst=0x55b3346c1d50, xSrc=<optimized out>,
ySrc=<optimized out>, xMask=0, yMask=0, xDst=0, yDst=0, width=3840,
height=2160) at damage.c:513
#4 0x000055b33201820c in CompositePicture (op=<optimized out>,
op@entry=1 '\001', pSrc=pSrc@entry=0x55b3346c1420, pMask=pMask@entry=0x0,
pDst=pDst@entry=0x55b3346c1d50, xSrc=xSrc@entry=0, ySrc=ySrc@entry=0,
xMask=0, yMask=0, xDst=0, yDst=0, width=3840, height=2160) at picture.c:1547
#5 0x000055b331fc85d3 in compWindowUpdateAutomatic (
pWin=pWin@entry=0x55b3343a6bc0) at compwindow.c:705
#6 0x000055b331fca029 in compPaintWindowToParent (pWin=pWin@entry=0x55b3343a6bc0)
at compwindow.c:729
#7 0x000055b331fc9fbb in compPaintChildrenToWindow (pWin=0x55b333e77b50)
at compwindow.c:744
#8 0x000055b331fca59f in compScreenUpdate (pClient=<optimized out>,
closure=<optimized out>) at compalloc.c:57
#9 0x000055b331f3abf4 in ProcessWorkQueue () at dixutils.c:536
#10 0x000055b3320aaa51 in WaitForSomething (are_ready=<optimized out>)
at WaitFor.c:192
#11 0x000055b331f361a9 in Dispatch () at dispatch.c:421
#12 0x000055b331f39cec in dix_main (argc=13, argv=0x7ffcf273f538,
envp=<optimized out>) at main.c:276
#13 0x000055b331f247de in main (argc=<optimized out>, argv=<optimized out>,
envp=<optimized out>) at stubmain.c:34
Fortuitously, that drawable was also fully clipped so that it took an
early exit and so we can hide the segfault by delaying querying the
pixmap until after the clip check.
The ongoing mystery is how we ended up in that state in the first place.
Closes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/204
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the clear-residuals security fix on gen7, context switches are
very slow. If X is being used with DRI clients, those clients will
typically be using the 3D engine for themselves and every frame
presented will then be copied by X, causing at least a couple of context
switches per frame. That greatly diminishes throughput, but if we prefer
to use the blitter engine for X, we can mostly keep off the render engine
avoiding the context thrash.
Reported-by: Rafael Ristovski <rafael.ristovski@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add 8 and 30 to the list of supported screen depths. The colorkey
massaging will be handled by the kernel so we don't have to worry
about it unlike with the sprite colorkey uapi.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cannonlake, then Icelake introduce new instruction formats and state
command, and require a new render backend to be written. Avoid selecting
the gen9 backend as this will hang!
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1864
Fixes: 3d5a1238af ("sna: Restore blt fallback backend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The back buffer of window/pixmap is invalidated by DRI2ScheduleSwap, and
is not available until the client calls DRI2GetBuffers. If they try to
use their old handles, they will only get stale data. Similarly if they
ask us to DRI2CopyRegion before the GetBuffers has reallocated a new
back buffer, that back buffer is stale. Since the back buffer is
out-of-date [likely containing data from a couple of swaps ago], we
should ignore the copy to avoid glitching [by hopefully having a less
noticeable glitch!] It's not entirely clear what the client intended at
this point...
Closes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/195
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Import the kernel's i915_pciids.h, up to:
commit 8717c6b7414ffb890672276dccc284c23078ac0e
Author: Lee Shawn C <shawn.c.lee@intel.com>
Date: Tue Dec 10 23:04:15 2019 +0800
drm/i915/cml: Separate U series pci id from origianl list.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before we indicate return control of the SHM Pixmap to the client (that
is prior to the next XReply), we ensure that the original SHM buffer is
uptodate with any changes made on the GPU. We must flush the GPU writes
back to the CPU and so not allow ourselves to keep the dirty cache of
the GPU bo.
Closes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/189
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Tested-by: Alexei Podtelezhnikov <apodtele@gmail.com>
A typo in tightly_packed define for builds with optimisation disabled
left us creating many packed objects. When compiled with -fno-common the
compiler rightfully complains about the duplication.
Signed-off-by: Alexei Podtelezhnikov <apotele@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In mesa i915/i965 pass the bpp to use when creating the surface, but the
gallium state tracker passed the depth. As it happens that
BitsPerPixel(format) will do the right thing for both, use that.
| DRI2ATTACH_FORMAT { attachment: CARD32
| format: CARD32 }
|
| The DRI2ATTACH_FORMAT describes an attachment and the associated
| format. 'attachment' describes the attachment point for the buffer,
| 'format' describes an opaque, device-dependent format for the buffer.
Should we need to use an explicit format (heavens forbid as nobody likes
DRI2) then that will have to start in the range above 256 (or higher).
For now the convention is defined by the mixture of i965/iris, and that
is to assume it is essentially a depth.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4569
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix the accidentally swapped bpp and depth values passed to
the addfb ioctl when we're testing for dirtyfb presence.
Currently the addfb fails every time so we don't even test
the actual dirtyfb ioctl.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit b5ac286c9b as it escaped before being completed.
It proved it's worth in preventing sna from hogging the GPU for too long
under x11perf stress, but it didn't check to see if there was enough
space left in the batch before emitting the dword. Simply revert the
patch for now.
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Closes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/174
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Issue tracking has been moved from a bugzilla instance to a gitlab
instance to go alongside and integrated with the gitlab repo, still all on
freedesktop.org.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We detect when the number of boxes we wished to emit into the batch
would overflow, but then miscalculated the number that would actually fit.
References: https://bugs.freedesktop.org/show_bug.cgi?id=112296
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since "Make PixmapDirtyUpdateRec::src a DrawablePtr" in xserver, the
"src" pointer might point to the root window (created by the server)
instead of a pixmap (as created by xf86-video-intel). Use
get_drawable_pixmap to handle both cases.
When built with -fsanitize=address, the following test on a hybrid
graphics laptop will trigger a heap-buffer-overflow error due to
to_sna_from_pixmap receiving a window instead of a pixmap:
xrandr --setprovideroutputsource modesetting Intel
xrandr --output DP-1-1 --mode 2560x1440 # should not crash
glxgears # should display gears on both screens
With nouveau instead of modesetting, it does not crash but the external
monitor remains blank aside from a mouse cursor. This patch fixes both.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100086
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111976
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Minimise preemption latency by frequently checking for pending preemption
events in between X11 client requests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
sna_display.c: In function ‘crtc_init_gamma’:
sna_display.c:7462:28: warning: unused variable ‘lut’ [-Wunused-variable]
sna_display.c:7444:14: warning: unused variable ‘sna’ [-Wunused-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Deal with xserver commit 8e3b26ceaa86 ("Make PixmapDirtyUpdateRec::src
a DrawablePtr")
Not sure this is still correct though. Is this stuff limited to
pixmaps anymore?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The minimum CS URB entry size is 1. Let's use that
instead of 0 so that we don't end up left shifting
a -1.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Use a cast to avoid the "left shift of negative value
[-Wshift-negative-value]" warning, and get rid of the
suppression.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The compiler seems to think src/mask xoff/yoff can be used
uninitialized. Zero them to make sure.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Just access both halves of the motion vector thing
directly instead of doung the cast to uint and deref.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Replace the cast+deref with memcpy() so that we don't upset
the compiler's strict aliasing rules.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Just access the xGlyphInfo members directly to avoid the
compiler getting upset about strict aliasing violations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
../src/intel_device.c: In function ‘__intel_open_device__pci.isra.6’:
../src/intel_device.c:321:25: warning: ‘%s’ directive writing up to 255 bytes into a region of size 247 [-Wformat-overflow=]
sprintf(path + base, "%s", de->d_name);
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Use an empty {} as the terminator in intel_device_match[] to avoid
the warning about missing initlizers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Duplicate a bit of code in FbDoLeftMaskByteRRop() switch statement
to avoid the fall through.
And while at it sort the cases based on the left byte and length.
Makes the pattern matcher in my brain much happier.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Refactor the BR13 color depth setup to common helper. This
eliminates a bunch of implicit fall through warns.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
gcc doesn't like extra stuff in the fall through comments.
Replace them with the standard form.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
../src/sna/sna_composite.c:567:11: warning: variable ‘sx’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
int16_t sx = src_x + tx - (dst->pDrawable->x + dst_x);
^~
etc.
I had a quick look at a few of the cases and they seemed fine to me,
so feels like gcc just being dense.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
If we change scanout status (i.e. whether or not this flip chain may be
presented directly on the CRTC), throwaway the previous back buffer
cache as those buffers may not be suitable for presentation.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=111197
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the backbuffer is stale (i.e. the client didn't call DRI2GetBuffers
before swapping) the front/back bo may not be distinct. Move the
assertion for a valid swap after the handling of a stale swap so that
the assertions are more robust for a client error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111197
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Check for a stale backbuffer (the client didn't call DRI2GetBuffers
between DRI2SwapBuffers) before asserting so that we should be
more resilient with asserts enabled for client errors.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111197
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Aurelien Rebourg
Chris Wilson
Ville Syrjälä
Liwei Song
Alexei Podtelezhnikov
Hanno Böck
Peter Wu