With the colorkey setup fixed the sprite Xv adaptor works just
fine with depth 30.
With depth 8 there is one remaining problem with the usage of
the LUT for gamma vs. C8, but that is purely a kernel issue.
Let's allow both depth 8 and depth 30 with the sprite Xv
adaptor.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Set up the colorkey correctly for depth != 24. For 8bpc we
need to replicate the same key value into each channel, for
depth 15/16 we need to mask off the unused low bits in each
channel, and for depth 30 we just use the 8 msbs of each channel
as the colorkey register can't hold the full 10 bits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
'debug' is a reserved option name since meson 0.48. So we
must rename our own debug option to something else. Let's
go with 'internal-debug'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If Xinerama is enabled, RandR is disabled and calling into RR functions
merely explode, so don't.
Reported-by: Mariusz Białończyk <manio@skyboo.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108495
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 af36a4ab78 ("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>
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 af36a4ab78
"sna: Defer submission of the next shadow frame until halfway through").
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
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>
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>
During early init, xf86ScrnToScreen() may return NULL, so handle that
possibility inside the assert.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
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>
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>
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>
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>
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>
Add the Coffeelake PCI IDs based on the following kernel patches:
commit b056f8f3d6b900e8afd19f312719160346d263b4
Author: Anusha Srivatsa <anusha.srivatsa@intel.com>
Date: Thu Jun 8 16:41:05 2017 -0700
drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having requested an inactive snooped buffer, we know that it is
already flushed and do not need to flush it again. With debugging
enabled, we hit an assert while flushing that the buffer has a refcout,
which at this present time of being plucked from the snoop cache it does
not.
Reported-by: Adric Blake <promarbler14@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=104341#c2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Very early on when creating the sna privates, we call to_sna(scrn) before
we have even set the sna->scrn backpointer. Reorder the code such that
we always set sna->scrn before the first to_sna() so that the
assert(to_sna(scrn)->scrn == scrn) can always hold.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to manipulate a bo from the active cache for reuse, then we
have to be careful not to immediately close it as it is still referenced
from the current batch.
Reported-by: Adric Blake <promarbler14@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103025#c44
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä
Chris Wilson
Liwei Song
dom.constant@free.fr