Commits on Source (42)
-
Ville Syrjälä authored
SKL reintroduced plane scaling once more. Let's try to make use of it. The one annoying caveat is that you can't do colorkeying and scaling at the same time :( For now we'll leave the choice of colorkey vs. scaling to the user via that XV_ALWAYS_ON_TOP attribute. One possible idea for improving the situation would be to add support for autopaint colorkey, and automatically disable the colorkey whenever the window is not obscured by anything and autopaint colorkey is enabled. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Use do{}while(0) for DBG() and ERR() to avoid isses with if/else/etc. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Ville Syrjälä authored
IPC_RMID_DEFERRED_RELEASE is unused so nuke it. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Ville Syrjälä authored
Allow building the driver with meson. Could probably use plenty of cleanups, but at least it gives me a working driver. And I think I managed to make it build everything that autotools builds. Quite a few compiler warnings were suppressed as well. Might want to look at those at some point. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
The PICT_ are enums and so never report true to ifdef PICT_a2r10g10b10 and instead we need to check the xserver version they were introduced. Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Before checking st_rdev, we first need to validate that the file is a device node, but we only want to check the file type bits and not compare the permissions. Reported-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Oops. We never actually select the NV12 shader on gen8, causing us to render garbage. Looks like this is the only one I somehow missed. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Use the new "COLOR_ENCODING" plane property to implement the XV_COLORSPACE port attribute for sprite Xv adaptors. v2: assert(colorspace < ARRAY_SIZE) (Chris) Cc: Jyri Sarha <jsarha@ti.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
dom.constant@free.fr authored
For my HTPC setup, I'm using the option "CustomEDID". With this option, output attaching and destroying events leads to crashes. The following sequence leads to a crash: - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin" - Starting Xorg - Connect HDMI2 - Disconnect HDMI2 - Reconnect HDMI2 -> Crash The crash happens in xf86OutputSetEDID (xorg/xserver/hw/xfree86/modes/xf86Crtc.c) at "free(output->MonInfo)". MonInfo is assigned with sna_output->fake_edid_mon which is allocated by intel driver in sna_output_load_fake_edid (src/sna/sna_display.c). Sequence details: - Starting Xorg -> fake_edid_mon is initialized - Connect HDMI2 -> xf86OutputSetEDID is called: - MonInfo is NULL - MonInfo is assigned with fake_edid_mon pointer - MonInfo is read by Xorg - Disconnect HDMI2 - Reconnect HDMI2 -> xf86OutputSetEDID is called: - MonInfo is freed thus also fake_edid_mon - MonInfo is assigned with fake_edid_mon - MonInfo is read but it was freed -> CRASH The fix consists of a new instance of xf86MonPtr for each calls of xf86OutputSetEDID. is initialized with fake_edid_raw which render fake_edid_mon useless. With this proposal, the behaviour of an EDID override is similar to a "real" EDID. Signed-off-by:
Dominique Constant <dom.constant@free.fr> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
During early init, xf86ScrnToScreen() may return NULL, so handle that possibility inside the assert. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Since forever we have been passing region=NULL when doing a windowed swapbuffer on vblank, and using that to mark the entire pixmap as being damaged. For an uncomposited window, this is incorrect as it points to a clipped region of the ScreenPixmap and so we were marking the entire ScreenPixmap as being flushed, but only having operated on the windowed region. Instead pass along the clip extents if region is unset. References: https://bugs.freedesktop.org/show_bug.cgi?id=105720 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
The update for ABI 22 and NotifyFd left behind an important flush for shadow rendering. Fixes: 4ab9145c7748 ("Update to ABI 22 and NotifyFd") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Do not immediately post the next shadow flip on completion of the current flips, but instead queue a timer for half way through the next vblank so that try to we keep the additional input-output lag to less than a frame. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Do not try and workaround the failure by forcing the wait-for-flip as we may be inside a vblank handler already. Just report the move failed and expect the caller to skip the draw, fairly standard practice for allocation failure handling (stale output rather than crash). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
We shouldn't even be attempting to redisplay if there are flips pending, so exit early and expect to be called again after the pending flips complete. Exiting early avoids having to call sna_mode_wakeup() in what used to be a potentially recursive manner (see commit af36a4ab "sna: Defer submission of the next shadow frame until halfway through"). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
TearFree wants to grab the most recently used scanout for rendering the next frame into. If the flip event was still pending, we would then query the drm event buffer for any pending completions, but this would proceed to execute all the other events before the flip events as well. Since we they were out of sequence, we pushed them into a buffer to execute afterwards, however we forgot the side effects of the flip handlers, for example see commit af36a4ab ("sna: Defer submission of the next shadow frame until halfway through") and that there may have been events read from drm into a local buffer inside sna_mode_wakeup() that haven't been processed yet. Eliminate the need for calling sna_mode_wakeup() by ensuring that all flip events have been completed first before handing the vblank callbacks and potential drawing, ensuring the correct ordering. References: https://bugs.freedesktop.org/show_bug.cgi?id=105720 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
kgem_bo_map__(cpu|gtt) leaves the sync up to the caller, in particular so that the obtaining the pointer and controlling the cache domains are not conflated and can be separated. However, it does mean that the caller can not assume that obtaining the pointer updates the cache domains, as it does not. memcpy_copy_boxes fell into this trap. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
When we mix TearFree and per-crtc pixmaps (e.g. for RandR transformations), we stash the old buffer on the CRTC for double buffering. However, this buffer needs to be reallocated when we change output resolutions, as the CRTC size may change. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
We were telling the kernel the correct location for it to fill the 64b relocation, but we were writing the presumed offset into the wrong pair of dwords in the batch ourselves. For the frequent case where we used a new upload buffer, the kernel would perform the fixup and correct our mistake, but if we happened to reuse a buffer then we told the gpu to source the stipple from the wrong address. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105886 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Having just chased a bug along this path, I found the following debug helpful in a narrowing down why certain paths were chosen. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
If the device is already wedged (no GPU), jump straight to the swrast path for performing the per-crtc transformations. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105420 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
TimerSet scales linearly with the number of elements in the queue as it performs an insertion sort, duplicating the sorting we also perform to keep the per-crtc vblank queue in an orderly fashion. As we already maintain the ordered timeline of vblanks, we can simply queue the next when the current vblank completes. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
video->plane is never populated so nuke it. Its only user can be nuked as well since all it's trying to do is turn off the plane (which fails on account plane_id being zero). We don't need to disable the plane immediately upon the setplane failure as the higher level code will end up stopping the entire port on error, and thus the plane will get disabled just fine. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
The kernel may reject the setplane due to eg. exceeding the max downscaling limit of the hardware. In that case let's retry the operation but let the GPU do the scaling for us. Tested on my IVB, after hacking the kernel to reject setplane which exceeds the max hw downscaling limit. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Liwei Song authored
Add the Coffeelake PCI IDs based on the following kernel patches: commit ccfd13215fd25a0e8c28221f3acc0dcaec11cd15 Author: Anusha Srivatsa <anusha.srivatsa@intel.com> Date: Thu Jun 8 16:41:06 2017 -0700 drm/i915/cfl: Add Coffee Lake PCI IDs for H Sku. Signed-off-by:
Liwei Song <liwei.song@windriver.com>
-
Liwei Song authored
Add the Coffeelake PCI IDs based on the following kernel patch: commit d29fe702c9cb682df99146d24d06e5455f043101 Author: Anusha Srivatsa <anusha.srivatsa@intel.com> Date: Thu Jun 8 16:41:07 2017 -0700 drm/i915/cfl: Add Coffee Lake PCI IDs for U Sku. Signed-off-by:
Liwei Song <liwei.song@windriver.com>
-
Chris Wilson authored
We only need DRI1 to support UMS on i810, but modern Xservers don't support DRI1 and the support infrastructure is no longer being shipped on some distributions. Gracefully fail if we can't compile the DRI1 code blocks for i810. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
exa_wm_yuv_rgb.g5a is identical to exa_wm_yuv_rgb.g4a. Just use a symlink intead of duplicating the whole file. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Our current yuv->rgb shaders follow the BT.601 conversion formula. Rename the shader sources to indicate that fact. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Allow the client to select between BT.601 and BT.709 via the XV_COLORSPACE port attribute with the textured Xv adaptor as well. Since the BT.601 coefficients are currently hardcoded in the yuv->rgb shader, let's just add a mostly duplicated shader with hardcoded BT.709 coefficients instead. Not the most elegant solution but avoids having to touch any state setup etc. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
On SKL+ dst color keying only works between the first sprite and the primary. We probably wante the first Xv port to be the first sprite plane so that the user gets working colorkeying for the port that is most likely to be used first. No way to get dst colorkeying with the other ports :( Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Not all sprite planes support RGB565. Insrtead of hardcoding which platforms have it let's ask the kernel instead. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Starting from ~KBL planes can do NV12. Let's make use that capability in the sprite Xv adaptor. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Even unscaled NV12 needs the plane scaler on SKL+, so when unscaled NV12 setplane fails we should still take the GPU scaling fallback path. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
When we're trying to reinstate the colorkey we might fail on account of the plane still being enable with a configuration that prevent the use of colorkey. This happens easily with NV12 since the plane scaler required by even unscaled NV12 is not compatible with colorkey. To work around the problem let's try disabling the plane first, then re-enable the colorkey, and finally we will try to re-enable the plane. The plane re-enable may fail, in which case we'll head to the GPU scaling fallback path. The cost is a flash of the colorkey when the plane blink off and then back on. Help me atomic ioctl, you're my only hope! Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
On SKL+ the dst colorkey is enabled on the primary plane instead of the sprite plane. That means the restriction of scaling vs. keying doesn't actually apply here as we never scale the primary. So let's remove the requirement of having XV_ALWAYS_ON_TOP enabled to get hw scaling. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Ville Syrjälä authored
Looks like we need a libdrm dep on intel_drv. Build fails for me on Arch. In file included from ../src/intel_device.c:51: /usr/include/xf86drm.h:40:10: fatal error: drm.h: No such file or directory #include <drm.h> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
It's 32bpp, depth 24 (for x8r8g8b8 pixel format), not 32 for everything. Just to be on the safe side, pick the more common x8r8g8b8 format. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Deferring the flush until Mesa checks its DRI2 buffer status only works so long as Mesa is checking its DRI2 buffers. Hint, it doesn't.... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97914 References: https://bugs.freedesktop.org/show_bug.cgi?id=52930 References: https://bugs.freedesktop.org/show_bug.cgi?id=90264 References: https://bugs.freedesktop.org/show_bug.cgi?id=101819 References: https://bugs.freedesktop.org/show_bug.cgi?id=101620 Fixes: 1f6dfc9d ("sna: Only flush GPU bo for a damage event") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Liwei Song authored
Add more Coffeelake PCI IDs based on the following kernel patch: commit c99d7832dcd7423ba352386107118b9bd8b83158 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Wed Dec 20 10:29:19 2017 -0800 drm/i915/cfl: Adding more Coffee Lake PCI IDs. Signed-off-by:
Liwei Song <liwei.song@windriver.com>
-
Chris Wilson authored
Import the kernel's i915_pciids.h, up to commit d0e062ebb3a44b56a7e672da568334c76f763552 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Fri Aug 3 16:27:21 2018 -0700 drm/i915/cfl: Add a new CFL PCI ID. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Sometimes the write simply do not land until later, requiring us to be very careful in how we perform domain tracking. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
man/meson.build
0 → 100644
meson.build
0 → 100644
meson_options.txt
0 → 100644
src/legacy/i810/meson.build
0 → 100644
src/legacy/i810/xvmc/meson.build
0 → 100644
src/meson.build
0 → 100644
File moved
src/render_program/exa_wm_yuv_rgb_bt601.g5a
0 → 120000
src/render_program/exa_wm_yuv_rgb_bt601.g6a
0 → 120000