On older versions of pixman, pixman_blt() can return false if the images
are <= 8bpp. If we are being called from CopyArea, then we cannot return
FALSE here as that will trigger an infinite recursion. Instead we must
manually perform the fallback using fbCopyArea().
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is some fallout from my xvmc cleanup.
Original-Patch-by: Rico Tzschichholz <ricotz@t-online.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we need to allocate a new bo for use as a gpu target, first check
if we can reuse a pixmap that has already been relocated into the
aperture as a temporary target, for instance a glyph mask or a clip mask.
Before:
backend test min(s) median(s) stddev.
xlib firefox-planet-gnome 50.568 50.873 0.30%
xcb firefox-planet-gnome 49.686 53.003 3.92%
xlib evolution 40.115 40.131 0.86%
xcb evolution 28.241 28.285 0.18%
After:
backend test min(s) median(s) stddev.
xlib firefox-planet-gnome 47.759 48.233 0.80%
xcb firefox-planet-gnome 48.611 48.657 0.87%
xlib evolution 38.954 38.991 0.05%
xcb evolution 26.561 26.654 0.19%
And even more dramatic improvements when using a font size larger than
the maximum size of the glyph cache:
xcb firefox-36-20090611: 1.79x speedup
xlib firefox-36-20090611: 1.74x speedup
xcb firefox-36-20090609: 1.62x speedup
xlib firefox-36-20090609: 1.59x speedup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we only use the glyph cache for small glyphs, those large than 32x32
will first be copied to a bo and used as a mask in a composite
operation. We can avoid the allocation and upload per use by allocating
a bo for the over-sized glyph from the start. As the glyph is large
anyway, the excess memory allocation is less significant.
Using normal font sizes, firefox shows no change - as expected. However,
using the 36 font size traces, we see around a 10% improvement on g45.
Before:
xcb firefox-36-20090609 127.333 127.897 0.22%
xcb firefox-36-20090611 87.456 88.624 0.66%
xcb firefox-20090601 19.522 20.194 1.69%
xlib firefox-36-20090609 201.054 201.780 0.18%
xlib firefox-36-20090611 133.468 133.717 0.09%
xlib firefox-20090601 23.740 23.975 0.49%
With large glyphs in bo:
xcb firefox-36-20090609 117.256 118.254 0.42%
xcb firefox-36-20090611 79.462 79.962 0.31%
xcb firefox-20090601 19.658 20.024 0.92%
xlib firefox-36-20090609 185.645 188.202 0.68%
xlib firefox-36-20090611 123.592 124.940 0.54%
xlib firefox-20090601 23.917 24.098 0.38%
Thanks to Owain G. Ainsworth for the suggestion!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid an infinite recursion after enabling CopyArea to use
the put_image acceleration to either stream a blit or to copy in-place,
we cannot call CopyArea from put_image for the fallback path. Instead,
we can simply call pixman_blt directly, which coincidentally is a tiny
bit faster.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This slighlty improves xrender performance on fence reg starved
i8xx hw.
I've also changed a few function calls to the new names from the
compat ones while looking at the code.
The i915 textured video path is not converted because atm the xv
code does not use tiled surfaces.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We appear to have a confusion of stride in terms of pixels, pitch in
terms of bytes and the actual width of the surface.
i830_pad_drawable_width() appears to be operating aligning *pixels* to a
64 pixel boundary and has never used the chars-per-pixel causing
considerable confusion in its callers. Remove the parameter and ensure
that the callers are expecting a value in pixels returned, multiplying
by cpp where necessary to get the pitch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Caught by a malloc library assert.
Note to self: Don't just copy&paste codelines around :(
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27540
Tested-by: Nick Bowler <nbowler@draconx.ca>
Tested-by: Calvin Walton <calvin.walton@gmail.com>
For some reason I've made a mess out of the overlay stride constrains.
Fix it up.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Calvin Walton <calvin.walton@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27453
In my recent fix for the chroma pitch for i915 xvmc I've forgotten about
i965 class hw. For videos with a non-even sized stride (measured in dwords)
the chroma pitch was internally incosistent and one dword off.
Fix this by using pitch2 for the chroma pitch in i965 textured video like
everywhere else.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27417
Tested-by: Nick Bowler <nbowler@draconx.ca>
Tested-by: Sven Arvidsson <sa@whiz.se>
Simply store the desired bo size in intel_xvmc_context and initialize
it in the driver's create_context function.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... by putting struct intel_xvmc_surface at the beginning. Also kill
the common context handling code and simply keep a pointer in the
surface private to the context.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's unused. Also drop all related generic code that tries to do
clever stuff with this callback. These are all remnants from a
pre-gem world.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All of these are also stored in the context. Also kill the context
reference counting. Doesn't serve a purpose besides occupying a
pointer to the context in the private surface struct.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... by putting struct intel_xvmc_surface at the beginning. This
will allow to consolidate surface and bo handling.
Also kill some now dead code used to handle the common surface
structure.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only passed around and actually used the gem handle. Don't
need a struct for one field alone ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And kill all the static structures. This way it's clearer what's
common and what's specific. And the code is shorter too.
Also clean up src/i830_hwmc.c - kill the nonstandard surface types
for i915 and the associated code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doing the same with the i965 code will allow us to share the
create_context function.
src/i915_hwmc.h is now almost empty. Move the last #defines to
src/xvmv/i915_xvmc.c where they are actually used and delete the
file.
Also rename the ddx context struct to something sane.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like for the subpicture stuff, share the "do-nothing" functions ...
And fix function name spelling, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like for i915. Also drop that now totally superflous limit on the
available surfaces.
Move the surface struct into the userspace library header now that
the ddx doesn't use it anymore.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The XvMC driver api in the server is insane. Even for optional stuff
like subpicture support it doesn't check for NULL-pointers. So we
have to retain some dummy functions.
Wonder how many copies of these things exist on fdo ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both xvmc are handing in the bo in the exact same way. So move the code
to src/i830_video.c and kill this great oeuvre of spaghetti-code.
The xvmc driver ini and fini also lost their last use, kill them, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After unifying i915 and i965, not much will be left of these files.
Therefore merge them to make the following changes easier.
This creates some warnings about some redefined macros, but when this
is all cleaned up they'll all be gone.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pauli pointed out that we take a ref on the front buffer when exchanging
but forget to release it. The ref is necessary since the set functions
will drop refs as necessary, but once we set the front buffer to point
at the back pixmap, we ned to release our private ref again, or we'll
leak buffers.
Reported-by: Pauli Nieminen <suokkos@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
After reports of segmentation faults caused by
d6b7f96fde and vmware, the most obvious
cause would be illegally writing to the src data when performing the alpha
fill inline. So force the image upload to go via a fresh buffer whenever
we need to modify the incoming data.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
On memory constrained hardware, tiling is vital for good performance as
it minimizes cache misses. The downside is that for older hardware
(which often suffers from the lack of bandwidth) requires the use of
fences for many operations, which are in short supply and so may cause
shorter batchbuffers. However our batch buffers are typically short and
so this is unlikely to be a concern and not affect the performance wins.
A quick bit of testing suggests the effect is inconclusive on
firefox/i945:
linear tiled
xcb 205.470 206.219
xcb-render-0.0 404.704 388.413
xlib 166.410 170.805
A secondary effect of the patch is to workaround a G31 specific hang
when attempting to use linear 2048x2048 surfaces. Bonus!
Fixes:
Bug 25375 - Performance issue using texture from pixmap (tfp) glx extension on 945
http://bugs.freedesktop.org/show_bug.cgi?id=25375
Bug 27100 - GPU Hung copying a 2048x1152 pixmap
http://bugs.freedesktop.org/show_bug.cgi?id=27100
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: John <jvinla@gmail.com>
Otherwise it would be a random value and drmmode_page_flip_handler()
won't have a chance to call I830DRI2FlipEventHandler() and indicate
a full page flip is complete.
Signed-off-by: Li Peng <peng.li@intel.com>
Fixes:
http://bugs.freedesktop.org/show_bug.cgi?id=27123
Fatal server error:
i915_emit_composite_setup: ADVANCE_BATCH: under-used allocation 100/104
Introduced with commit d6b7f96fde.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Do not try to fixup the alpha in the ff/shaders as this has the
side-effect of overriding the alpha value of the border color, causing
images to be padded with black rather than transparent. This can
generate large and obnoxious visual artefacts.
Fixes:
Bug 17933 - x8r8g8b8 doesn't sample alpha=0 outside surface bounds
http://bugs.freedesktop.org/show_bug.cgi?id=17933
and many related cairo test suite failures.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a number of cairo test suite failures.
Also affects:
Bug 16917 - Blur on y-axis also when only x-axis is scaled bilinear
http://bugs.freedesktop.org/show_bug.cgi?id=16917
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My cleanup accidently created a inconsistency in the YUV plane ordering.
I think we can safely assume that I'm colorblind ;)
As Carl Worth rightly pointed out, this change deserves a more elaborate
explanation:
For Xv planar formats, the three planes are stored consecutively in
memory, ordered Y U V. Now for some totally odd reason (= none at all),
i915 xvmc stored it in Y V U order. Right after the release of 2.10, with
commit "Xv: consolidate xmvc passthrough handling" I've inadvertently
broken xvmc support (which started this whole odyssey into xvmc). When
fixing stuff up, I neglected this special plane ordering and simply
assumed it to be the same as Xv and dropped that special case for i915 in
src/i830_video.c. This patch completes the change to standard YUV plane
ordering by making the corresponding change in src/xvmc/i915_xvmc.c.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just make it mirror ScheduleSwap: complete the wait on any error
condition so as not to crash the client if the kernel is misbehaving.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We can only handle 32 bit values unless we totally virtualize the count,
since the kernel only handles 32 bits itself. Rather than adding all
that overhead, just tolerate the occasional missed event everytime the
counter runs over.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
A couple more niggles: make sure we return a target_msc that at least
matches the current count; this is a little more friendly to clients
that missed an event. Also check for >= when calculating the remainder
so we'll catch the *next* vblank event when the calculation is
satisfied, rather than the current one as might happen at times.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
My merge of Mario's patch for this was botched. Fix it up so that OML
waits work correctly, and remove a bogus warning from ScheduleSwap.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The current code in I830DRI2ScheduleSwap() only schedules the correct
vblank events for the case divisor == 0, i.e., the simple
glXSwapBuffers() case.
In a glXSwapBuffersMscOML() request, divisor can be > 0, which would go
wrong.
This modified code should handle target_msc, divisor, remainder and the
different cases defined in the OML_sync_control extension correctly for
the divisor > 0 case.
It also tries to make sure that the effective framecount of swap
satisfies all constraints, taking the 1 frame delay in pageflipping mode
and possible delays in blitting/exchange mode due to
DRM_VBLANK_NEXTONMISS into account.
The swap_interval logic in the X-Servers DRI2SwapBuffers() call expects
the returned swap_target from the DDX to be reasonably accurate,
otherwise implementation of swap_interval for the glXSwapBuffers() as
defined in the SGI_swap_interval extension may become unreliable.
For non-pageflipped mode, the returned swap_target is always correct due
to the adjustments done by drmWaitVBlank(), as DRM_VBLANK_NEXTONMISS is
set.
In pageflipped mode, DRM_VBLANK_NEXTONMISS can't be used without severe
impact on performance, so the code in I830DRI2ScheduleSwap() must make
manual adjustments to the returned vbl.reply.sequence number.
This patch adds the needed adjustments.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Previous code only handled divisor == 0 case correctly. This should
honor a given target_msc for the divisor > 0 case and handle the
(msc % divisor) == remainder constraint correctly.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
If a drawable isn't visible due to DPMS or redirection, we'll just blit
it rather than schedule a swap event. However, we didn't reset the
target_msc, so the swap target we receive from the server could get out
of sync with the vblank count of the drawable's display. So at DPMS on
time, the swap target would be the last good vblank count plus some
large number (since the swaps won't have been throttled).
Solve this by zeroing out the swap target like we should when we fall
back to a blit. Also make the kernel error cases more friendly by
making them fall back to blits too.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Once we hit this error it's unlikely that we're coming back - so don't
flood the logs with redundant information.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This kills one wip remnant from my i830_memory cleanup and the last
remainings of the subpicture support.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the long long ago, fbOffset was used for DGA. The server now has
only one reference to fbOffset, a leftover setting of it in fbdevhw.
We can safely ignore it now, which is good since we weren't updating
it in other places where the front buffer offset could change.
We know that it's clobbered at each batchbuffer, anyway. And even if
this server isn't running DRI2, it can still be clobbered at batch
start in the KMS world.
The previous code made no sense, (multiplying an offset by 4 is
meaningless). It could have onlt worked with the offset being
fortuitously 0.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Like with the per context stuff, also drop the now artificial limit
on surfaces. Again, with that gone, a lot of code can be deleted.
Reviewed-by: Carl Worth <cworth@cworth.org>
There's now not a reason anymore to limit the number of active contexts.
So kill this accounting, too.
With that all gone, per-context state in the ddx is nil, so rip out
all associated code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Proper bo management ensures that the cpu doesn't step on buffers
used by the gpu. Drop the now unnecessary synchronization.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Cache coherency is now fully under the control of gem.
For lack of hw documentation, I had to find out the correct cache
placements by trial and error:
Backward and forward surfaces: I915_GEM_DOMAIN_RENDER
Correlation data: I915_GEM_DOMAIN_SAMPLER
Changing any of them leads to visual corruptions, so I think these
are the correct ones.
Reviewed-by: Carl Worth <cworth@cworth.org>
Now the last user of the fixed buffers provided by the ddx is gone!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
It works!
v2: Correlation data needs to be in the render cache!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
I've decided to allocate a new buffer for every render command, to
prevent stalling for the gpu. libdrm bo reuse should take care of
not wasting memory in case the buffer is not busy.
Also always emit the full state, it's not worth it to complicate
the code over a few stores to wc memory.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Like with one_time_state_emit, this preps for relocatable bo's.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
This also starts to kill the last remnants of the support for
physical addresses for the indirect state buffers. With gem this
would need kernel support (in the form of a new reloc type in
execbuf2).
This does not change the ABI between ddx and client libIntelXvMC.
I've decided to do this in one swoop when all the buffer rework is
done.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Seems to be a remnant from i810 XvMC support. last_flip is always 0,
so serves no real purpose anymore. Kill it and the associated code.
With last_flip gone, last_render also lost its purpose. Kill it, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
This is in preparation for real relocatable drm_bo's instead
of memory at a fixed address. By switching to the batchbuffer
macros (like i965 xvmc) we can use the nice OUT_RELOC macro.
Also align the code more with coding-style elsewhere, i.e. bitops
instead of bitfield structures. The bitfield structures are
quite a mess to work with the batchbuffer macros, so they were
getting in the way, anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
WIP code that hasn't changed for over two years is unlikely to
suddenly start progressing. Drop it. After all, git can easily
resurect it in cases it's needed.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Yes, this breaks binary compat of the struct passed around between
X ddx and the client libXvMC. But we always ship both, so they should
not get out of sync.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Kill the corresponding !bo path in i830_free_memory.
Also kill another remnant of the pre-kms era in the same file, while I
was looking at the code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
It doesn't bind anything anymore, but does a few random things.
Give it a hopefully vague enough name to cover all cases ;)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Besides the debug stuff the went away in the previous patch,
this stuff was totally unused ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Totally useless debug function from the pre-gem era. No point
to occasionally spam Xorg.log with a bogus "No memory allocations"
message.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
It's a left-over from the non-gem era and no longer used at all.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
On i965 class hw, kernel_exec_fencing was 1 always, anyway. And on
i945, this patch kills a memory leak (dunno how, but it does).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've accidentally broken i915 xvmc due to alignment constrains that
break my assumption that Y-pitch == UV-pitch*2. Fix this up by consistenly
using dstPitch2 for the Y-pitch. This also unifies the dst pitch
computation slightly, now that the i915 xvmc special case is gone.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25949
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(Minor edit to support compilation without INTEL_XVMC defined by
Carl Worth <cworth@cworth.org>)
In my previous cleanup I've inadvertedly dropped the offset adjustment
code for the xvmc passthrough case. Fix this up.
Also reimplement that ugly hack I've accidently killed to keep i915 class
xvmc a tad bit longer on life support.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: xunx.fang@intel.com
Rather than mangle the EDID block and hope the server does the right
thing, just build a sensible mode list up front. Do this for LVDS where
there is no EDID or where it does not claim to be continuous-frequency
(since in the latter case, the server will add reasonable modes for us).
Signed-off-by: Adam Jackson <ajax@redhat.com>
On 965 and up, if we detect a full height blit, we should just wait for
vblank, rather than try to do a scanline wait for the whole display.
On pre-965, doing a scanline wait followed by a blit works, but in the
full height case we need to give the blitter time to start up, so we
wait until the bottom line of the blit minus 2 padding scanlines to
accommodate.
Fixes FDO bug #22475.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This keeps us from trying to set tiling on it while pinned, which also
keeps us from trying to unpin it in the kernel, causing an error.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Check for page flipping support before enabling flip and vblank event
support needed for the new DRI2 APIs.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With DRI2 supporting multiple subsystems, the video driver must
initialize the list of driver names instead of just passing the single
driver name used by Mesa. Without this, the X server will fail to
initialize DRI2 as the numDrivers field in this structure will be
uninitialized.
Signed-off-by: Keith Packard <keithp@keithp.com>
Of course, it's still fail since you can't correctly composite
colorkey overlay, but at least this doesn't spam colorkey to the root
window.
Tested-by: Daniel Vetter <daniel@ffwll.ch>
If we get to the point where we check the divisor/remainder equation and
it's satisfied, we should complete the swap immediately.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The new interfaces allow for improved buffer swap, and support for the
SGI_swap_control, SGI_video_sync and OML_sync_control GLX extensions.
The Intel implementation allows page flipping to occur for swaps that
are full screen and not rotated.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The PRM (Vol 1, p32) specifies that the URB_FENCE command must not cross
a cache-line boundary (64-bytes) in order to workaround a silicon issue.
Ensure that it does not by inserting an alignment point before the atomic
section.
This is a slightly too large hammer, but the easiest method to work with
the current BEGIN_BATCH/ADVANCE_BATCH protections.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The mapping type to use is determined by the tiling of the underlying
object, not by whether or not not we control the vt. This was a
left-over wart that was intended to mean that we had GEM and so could
use GTT mappings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add a small wrapper function so that the callsites need only call the
single function when checking the available aperture size for
determining the maximum viable size for operations. This will allow us
to easily extend this set in the future by only needing to adding the
check to a single location.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This just makes it _really_ clear, what's supported. No other changes.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
It's now all in I830PutImageTextured. Also kill some leftovers
from XVMC-on-overlay support and ums-XVMC-on-i915 support. Plus
a small comment as a reminder for where to add i915 xvmc support
back in.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
I'm still curious as to why fixed-point semantics are necessary
for this generic XV helper function that's been causing all this.
Can modern X really run on hw without floating-point support?
Anyway, the ugliness is now all nicely under the carpet (in
i830_clip_video_helper).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
After this there are no other external users of these strange variables,
so we can nicely hide them somewhere in the next changeset.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This is the first part of my small crusade to rip out x1, x2, y1, y2
from I830PutImage*. These variables have strange semantics (they
change from simple integers to fixed-point values somewhere in
the middle) and don't really seem to be what we actually need.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
We always pass a non-null pointer for crtc_ret, no point to check
for this.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This wasn't making much sense anymore, and further cleanups will
make this even more apparent. This change just makes two copies of
I830PutImage and kills the not-applicable if-clauses in both
versions.
There is one small functional change in here: The textured video
path doesn't munch around with adaptor_priv->videoStatus anymore,
which is only used by the overlay. This could prevent the overlay
from being switched off if someone would use textured video at the
same time.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The variable "intel" is unused when building i830_video.c without XvMC
support which results in a compiler warning:
i830_video.c: In function 'i830_copy_video_data':
i830_video.c:1443: warning: unused variable `intel'
Trivial fix via #ifdef.
Now that libdrm 2.4.16 is released (and already required) we can
unconditionally enable this.
Please add something like this to the release-notes/NEWS file:
* Overlay support for kernel modesetting. This needs at least kernel
v2.6.33 to work. A backport to 2.6.32 is available at:
http://gitorious.org/daniel-s-linux-stuff/linux-kernel/commits/intel-kms-overlay-for-2.6.32
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 3f11bbec42.
For unknown reasons, enabling tiling for the glyph cache is causing
glyph corruption both across suspend and resume and VT switching, on a
wide range of chipsets (reports include both i8xx and gm45)
This strongly suggests that we are handling tiling, or updates to tiled
buffers, incorrectly across i915_gem_idle(). However, until we can find
the root cause, we want to fix this regression before the next stable
release, so simply revert this patch. :(
Fixes:
[Bug 25406] fonts garbled after resuming from suspend since 6729b508http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This should restore the previous level of synchronisation between
textures and pixmaps, but *does not* guarantee that a texture will be
flushed before use. tfp should be fixed so that the ddx can submit the
batch if required to flush the pixmap.
A side-effect of this patch is to rename intel_batch_flush() to
intel_batch_submit() to reduce the confusion of executing a batch buffer
with that of emitting a MI_FLUSH.
Should fix the remaining rendering corruption involving tfp [inc compiz]:
Bug 25431 [i915 bisected] piglit/texturing_tfp regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25431
Bug 25481 Wrong cursor format and cursor blink rate with compiz enabled
http://bugs.freedesktop.org/show_bug.cgi?id=25481
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In commit 98e11210
Remove flush parameter from intel_batch_flush()
Maxi spotted that I had broken screen updating. It appears in my haste
to eliminate the extra parameter I removed a call to intel_batch_flush()
when throttling, i.e. when pushing the updates to the screen before
idling.
Should fix:
Bug 25409 [bisected] rendering corruption since a938673ehttps://bugs.freedesktop.org/show_bug.cgi?id=25409
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we wedge the GPU then we will return -EIO for the current batch and
then attempt to reset the GPU. Meanwhile the X server detects the error,
throws a FatalError and to all intents and purposes appears to crash to
the user - whereas before it often just appeared to momentarily freeze.
Of course, on older hardware the server remains frozen until we can find
a way to reset those GPUs at runtime.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is only a single caller that wishes to forcibly append a flush
into the batch: intel_sync(). So move the logic there.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During shutdown from a FatalError during batchbuffer submission, it is
possible for the batch_ptr to be NULL, so we must be careful not to
append a flush on this error path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since drm may not actually set the appropriate errno after a failure, we
must use the return code instead when determining the cause of failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the 3 conditions into the 2 distinct cases. This has the
secondary benefit of also distinguishing between the reported errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel will only emit a flush iff the buffer is currently owned by
the GPU. Instead of presuming that the kernel must emit a flush, it is
safer to assume that it does not and so cannot mapping the buffer on to
the CPU as a synchronisation point. The most obvious counter-example is
when we map the same buffer twice without using it in a batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These files have been dropped from the generated tar file since the
removal of UMS support. However, the bios_reader code still includes
these, so "make distcheck" fails unless these are distributed.
There's probably a cleaner fix possible, but this at least fixes the
build so that the snapshot can be pushed out.
On older chipsets (i.e. pre-i965) tiling is very restrictive and imposes
severe size and alignment constraints. Combine that with relatively
small apertures and it is very easy to create a batch buffer that
cannot be mapped into the aperture (but would otherwise fit based purely
on total object size). To prevent this we need to not use tiling for large
buffers (the very same buffers where tiling would be of most benefit!).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
make dist failed due to missing i2c_vid.h
Commit b9b159c498 Remove UMS support.
The above commit did not remove this header file from the makefile.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
When updating a buffer object for the framebuffer, we may need to
allocate a fresh pixmap private structure, for example if the pixmap is
replaced due to resize. When doing so it is then imperative to
initialise the circularly linked lists correctly.
Should fix the fault:
#0 i830_set_pixmap_bo (pixmap=0x24ab380, bo=0x24ab780) at i830_uxa.c:524
#1 0x00007f8615c629fd in drmmode_xf86crtc_resize (scrn=0x247a320, width=1280, height=800) at drmmode_display.c:1345
#2 0x000000000051246c in xf86RandR12ScreenSetSize (pScreen=0x24824f0, width=<value optimized out>, height=<value optimized
out>, mmWidth=<value optimized out>, mmHeight=<value optimized out>) at xf86RandR12.c:709
#3 0x0000000000512aa8 in xf86RandR12CreateScreenResources (pScreen=<value optimized out>) at xf86RandR12.c:839
#4 0x0000000000514ec0 in xf86CrtcCreateScreenResources (screen=0x24824f0) at xf86Crtc.c:727
#5 0x0000000000424fb3 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:215
as reported by 'buscher'.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the copy uses the 2D blitter, it uses the render cache so the source
should not require flushing if it has previously been used as a
destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I still have no idea how this is triggering failures, but it is. So
revert until the problem is solved.
Should fix once again:
Bug 23803 [bisected i915] gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I incorrectly changed the logic in 285f286 and caused the batch to
always be flushed when debugging, instead of merely inserting a MI_FLUSH
between operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The compile cleanup was not without fault... Apparently I don't have
XVMC enabled anymore and so missed that this variable is actually used.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid waiting on dirty buffer object by streaming the upload to a fresh,
non-GPU hot buffer and blitting to the destination.
This should help to redress the regression reported in bug 18075:
[UXA] XPutImage performance regression
https://bugs.freedesktop.org/show_bug.cgi?id=18075
Using the particular synthetic benchmark in question on a g45:
Before:
9542.910448 Ops/s; put composition (!); 15x15
5623.271889 Ops/s; put composition (!); 75x75
1685.520362 Ops/s; put composition (!); 250x250
After:
40173.865300 Ops/s; put composition (!); 15x15
28670.280612 Ops/s; put composition (!); 75x75
4794.368601 Ops/s; put composition (!); 250x250
which while not stellar performance is at least an improvement. As
anticipated this has little impact on the non-fallback RENDER paths, for
instance the current cairo-xlib backend is unaffected by this change.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we track when a pixmap is active inside a batch buffer, we can avoid
unnecessary flushes of the batch when mapping a pixmap back to the CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ensure that the render caches and texture caches are appropriately
flushed when switching a pixmap from a target to a source.
This should fix bug 24315,
[855GM] Rendering corruption in text (usually)
https://bugs.freedesktop.org/show_bug.cgi?id=24315
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to detect when we require cache flushes we need to track which
domains the pixmap currently belongs to. So to do so we create a device
private structure to hold the extra information and hook it up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
Particularly noting to route alpha to the green channel when blending
with a8 destinations.
Fixes:
rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
introduced with commit 14109a.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
RENDER specifies that texels should sampled from the pixel centre. This
corrects a number of failures in the cairo test suite and a few
off-by-one bug reports.
Grey border around images
https://bugs.freedesktop.org/show_bug.cgi?id=21523
Note that the earlier attempt to fix this was subverted by the buggy use
of 1x1R textures for solid sources -- which caused the majority of text
to disappear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Instead of allocating and utilising the texture samplers for 1x1R
solid sources and masks we can simply use the default diffuse and
specular colour channels and adjust the fragment shader appropriately.
The big advantage is the reduction in size of batches which should give
a good boost to glyph performance, irrespective of the additional boost
from using simpler shaders.
However, the motivating factor behind the switch is that our use of 1x1
textures turns out to be buggy...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the immediate victim of the overflow would be to overwrite the maximum
permissible value, the test was optimistic.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since batch buffers are rarely emitted by themselves but as part of a
sequence of state and vertices, the whole sequence is emitted atomically.
Here we just enforce that batches are marked as being part of an atomic
sequence as appropriate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It can go up to 32k. Upping this lets me use my 2560x1600 and 1920x1200
monitors in an extended desktop configuration.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
XF86DRI is defined by the SDK so not defining it here just breaks the
build. Define HAVE_DRI instead to avoid collisions.
Note: DRI2 is still enabled/disabled entirely by SDK defines.
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove bo pin for surface buffer access, and remove access
attempt for possible unmapped framebuffer. Using xv buffer
pointer to pass current xvmc surface bo handler, which is
assigned to src image bo and handle that the same way as in Xv.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Fixed up for conflict against the XV rework. Not tested, because
both mplayer and xine segfault with XVMC currently.]
Signed-off-by: Eric Anholt <eric@anholt.net>
While copying and rotating the buffer, array access was out of bounds when
rotated to the right (RR_Rotate_270). My buffer handling changes probably
made this bug much more likely to actually result in a SIGSEGV.
I've checked the logs and the bug exists since rotation has been supported,
i.e. this looks like a candidate for cherry-picking for all supported
releases.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Kill some unnecessary stuff. Small code changes, but no functional ones.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This code didn't survive the global renaming of vars to saner names.
Fix it up.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Mostly unused definitions and variables, but also some strange ums
debug code. Also kill some now obsolete comments.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
If DEBUG_FLUSH_CACHES is enabled then emit a MI_FLUSH after every
rendering operation. This is intended to 'fix' cases where we are
missing a required flush in the middle of a sequence of operations, such
as switching between 2D to 3D and render to sampler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make the following options available via xorg.conf:
Section "Driver"
Option "DebugFlushBatches" "1" # Flush the batch buffer after every
# single operation;
Option "DebugFlushCaches" "1" # Include a MI_FLUSH at the end of every
# batch buffer to force data to be
# flushed out of cache and into memory
# before the completion of the batch.
Option "DebugWait" "1" # Wait for the completion of every batch buffer
# before continuing, i.e. perform synchronous
# rendering.
EndSection
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Failure to do so causes xrandr to report incorrect property values.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
By dropping the frontbuffer from the crtc, the new frontbuffer
can be properly added to the crtc when the xserver is reset.
Signed-off-by: Albert Damen <albrt@gmx.net>
Noticed this on Fedora, where 1.7 server does gamma via the randr
codepaths however kms doesn't have this call which happens in the
non set_mode_major path.
probably should be backported to released drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
It was cooking up insane alignment values for buffers that new libdrm was
justifiably complaining about, but it turns out we don't need the alignment
values anywhere because the only case they're needed, they're computed
entirely by the kernel. Also, the XVMC code was passing a completely unused
flag in.
This is the beginning of the campaign to remove some of the absurd use of
Hungarian in the driver. Not that I don't like Hungarian, but I don't need
to know that pI830 is a pPointer.
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
At this point, the only remaining feature regressions should be the lack of
overlay support (about to land), and the need to update the XVMC code to work
in the presence of KMS.
Acked-by: Keith Packard <keithp@keithp.com> (in principle)
Acked-by: Carl Worth <cworth@cworth.org> (in principle)
This does not restore the overlay on EnterVT/disable it on LeaveVT.
Does not look like this is necessary.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[anholt: Hacked in avoiding the actual kernel calls with
Signed-off-by: Eric Anholt <eric@anholt.net>
This is the last preparatory step for overlay support with drmmode.
Safe two (specially marked) function calls in the setup code, all
hw accessing code goes now through these three new functions with
the ums_overlay prefix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The basic idea is to only pin the buffer into the gtt when
the overlay hw is actually using it. This results in a few changes:
- Unify data copied/buffer handling with textured video. Now offsets
are always buffer relative and we just use drm_bo_map to access a
buffer.
- Implement double buffering using two bo's. This is necessary because
we can't pin the same buffer to the gtt and map it as normal memory.
- Kill XV_DOUBLE_BUFFER. With the above changes, overlay video is always
doubel buffered.
There is still the XvMC passthrough case, which makes the code slightly
ugly. Unfortunately we can't get at the bo behind this buffer.
Changes since the last review-round:
- Don't overallocate by a factor of 2.
- Prevent possible use-after-free issue.
Signed-off-by: Eric Anholt <eric@anholt.net>
This way all thes strange special cases make much more sense.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The code looks like it's been bitrotting since being copied over
from the i810 driver. Furthermore painting rgb pixmaps with the overlay
engine is in these days of modern compositing X an absolute no-go. And
textured video doesn't support it neither, so its likely never ever
used by applications.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
- scrap unused variable overlay
- scrap an superflous if and attach the code to the preceeding else
- tiny layout fix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Also scrap the unecessary variable sync in I830PutImage and the
accompanying obfuscated logic.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Just moves the code and passes back allocation failures.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Just move the code and pass back allocation failures.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
It's only used to remember that XvMC has ỲV12 as output. is_planar_fourcc
already takes care of that in all necessary cases.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
The idea for the hw double buffering support is to program two fixed
buffers and then only switch buffers in the OCMD register. But the driver
as-is always programs the new buffer address (in both register sets
when double buffered). Therefore we gain nothing by using this hw
capability. Scrap the software support for it.
When double buffered, we now allocate just a buffer of size 2*size and
switch between the two parts purely in software.
To make reviewing this easier, I'll shortly explain the differences of how
double-buffering (i.e. tear-free video) is achieved before and after this
change:
- When double buffer, allocate a buffer twice the size (unchanged).
- Depending upon the currently shown buffer-half, copy the new frame into
the other buffer-half. In the old code this is done by using the right
set of buffer offsets, either *Buf0Offset or *Buf1Offset. The new code
simply programs the offset for the right buffer-half into the single set
of offsets. The end-result is unchanged.
Now the big difference in hw-programming:
Old: Programm new buffer offset into both sets of _hw_ buffer offset
registers. Depending upon the current _sw_ buffer, select the _hw_ buffer
and program this into the OCMD register. This just complicates matters
unnecessarly.
New: Just always use the hw buffer 0.
And then it's again the same story in both old and new code:
- Execute an overlay flip (MI_OVERLAY_FLIP) to read in the contents of the
hw registers into the shadow hw registers (which are actually being used
by the overlay, not the ones we write stuff into). This is synchronized
with the respective crtc vblank by the hw.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This function only programs the overlay and is never called for textured
video. Make this obvious.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
This slightly moves around (and simplifies) the OSTRIDE reg programming,
too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Also introduce an is_planar_fourcc helper. I'll use that one later.
In i830_display_video this changeset moves the XVMC case (previously
obscured as the default case) around. I've figured this default case
does not make sense, here's why:
XvMC is everywhere else handled as a planar format (e.g. in the register
programming a few lines down). Furthermore the id variable gets mapped
to FOURCC_YV12 if IS_I915(pI830) is true in I830PutImage. There's a
second caller in the offscreen overlay support code. But I think that
code is bitrotten and not reliable as an information source.
So we have a different behaviour only for id=FOURCC_XVMC and i965 class
hw (i830 class doesn't have xvmc). I've crawled through various
sources/intel documentations. Finally in the textured video implemention
for i965 class hw (src/i965_video.c) I've found a switch statement that
puts XVMC into the same case as I420 and YV12. So also in i965 class hw
xvmc uses a planar format.
In conclusion I claim that this code was bogus and XvMC on i965 class hw
over Xv overlay was most likely broken.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
When TV is not connected and X start, after plugging TV cable again,
system will crash because output crtc is NULL. This patch will return,
do not handle crtc immediately, meanwhile set value will be effective
until user really enable output by xrandr command.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
When the monitor is digital type for SDVO-DVI D, there should exist the EDID. If
there is no EDID, it should be detected as disconnected.
Signe-off-by: Zhao Yakui <yakui.zhao@intel.com>
This reverts commit 505025053d.
In theory, the non-affine paths work -- at least for the stated test case,
so re-enable them and avoid the slow work-around.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Projective texture coordinates must be delivered as TEXCOORDFMT_3D
using TEXCOORDTYPE_HOMOGENOUS. This meant selecting the correct type
in i830_texture_setup, the correct format in i830_emit_composite_state
and sending only 3 coordinates in i830_emit_composite_primitive.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: tweaked to fix up a couple of use-before-initialised]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The i915 and i830 take similar but different data when emitting the
primitives, instead of trying to share code here, just split this
apart and avoid potentially breaking things later on.
Signed-off-by: Keith Packard <keithp@keithp.com>
The xf86DiDGA code required that the scanout buffer always be
mappable, stay be at a fixed address in the aperture and have a
constant size. With frame buffer resizing, the latter two are no
longer true, and with KMS, we'd really prefer to not allow the former.
The only option available to the driver is to completely disable DGA
as the modes code has internal calls to the xf86DiDGA code when
fetching new modes from the hardware.
A fix for the DiDGA code will be added to the X server which will
automatically initialize DGA for mode switching and input, but not
frame buffer access, and not require any driver cooperation.
Thus, the correct solution is for the driver to not call xf86DiDGAInit
at all. For old servers, this eliminates a potential catastrophic
problem where random memory is written by the X server. New servers
will get the DIX-based behaviour automatically.
Signed-off-by: Keith Packard <keithp@keithp.com>
Pre-2.0, the driver supported rotation internally, rather than relying
on the X server rotation support. The last piece of this dealt with
rotating the mouse coordinates and also tried to preserve rotation
across DGA/VidModeExtension modesetting requests.
That latter bit of code broke under KMS as the rotation value was
never initialized, and when set to zero would create an invalid
configuration. This would confuse xrandr which would bail before
making any changes, leaving the user without a way to recover.
Signed-off-by: Keith Packard <keithp@keithp.com>
There are definitely bugs in the 8xx code dealing with non-affine
transformations. Disable that code for now to get things working.
Fixes bug #22947 ([855GM, xf86-video-intel-2.8.0] "Freeze" when RENDER extension is being used)
Under KMS, the bufmgr is not initialized at InitOutput time and so it
won't be re-initialized during server regen. Thus we must leave the
bufmgr running during regen and cannot destroy it in CloseScreen.
Under UMS, each place the bufmgr is initialized, it checks to see if
it has already happened. Hence, we can safely leave the bufmgr running
across server regen for UMS too.
Signed-off-by: Keith Packard <keithp@keithp.com>
We can update the cursor without hiding and showing it. In fact, doing the
hide/show causes noticable flicker when running in KMS mode.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Currently when asked to composite using a gradient source or mask, we
fallback to using fbComposite(). This has the side-effect of causing a
readback on the destination surface, stalling the GPU pipeline. Instead,
like uxa_trapezoids(), we can use pixman to fill a scratch pixmap and then
copy that to an offscreen pixmap for use with uxa_composite().
Speedups on i915:
firefox-talos-svg: 710378.14 -> 549262.96: 1.29x speedup
No slowdowns.
Thanks to Søeren Sandmann Pedersen for spotting the missing
ValidatePicture().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My recent commit [94fc93] to use the pixel centre for sampling with the i830
broke the i915. This restores the previous sampling coordinates for the
i915 whilst preserving the correct coordinates for i830.
Fixes: gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And in particular we apply the nearest sample bias separately for
src/mask.
Fixes cairo/test:
device-offset-scale
finer-grained-fallbacks
mask-transformed-{similar,image}
meta-surface-pattern
pixman-rotate
surface-pattern-big-scale-down
text-transform
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not only were incorrectly falling back if we had non-affine
transformations, but we made the decision based on a stale transformation
matrix.
Related bug 22877:
batch_start_atomic horribly breaks performance after a while
https://bugs.freedesktop.org/show_bug.cgi?id=22877
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Maximilian Grothusmann <maxi@own-hero.net>
If set externally to a different level, this would result in a no-op.
OTOH if the display is switched off (DPMS) you do not want the change to take
place immediately, but rather to be saved and set later when the display is
active again.
As DGA is optional in xserver, we should check this too instead
of always trying to init DGA.
Found when update xserver to 6fffcd5825454a7fe58ffbcfb219f007cf38e731,
but not update xf86dgaproto, which caused X fails to start.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Previously the code would always return the count, before ever looking
into the _3d_cmds table to see if there was actually a valid command.
Thanks to Alan Coopersmith who reported that the code was confusing
parfait:
https://bugs.freedesktop.org/show_bug.cgi?id=21666
The KMS API doesn't provide for sharing a single bo for multiple
cursor images, so allocate one bo for each crtc to hold the cursor
image. KMS also only supports ARGB cursors, so don't bother to
allocate buffers for two color cursors.
Signed-off-by: Keith Packard <keithp@keithp.com>
Cursor images may need rotation, or positions updated when new modes
are set. The server provides a convenience function,
xf86_reload_cursors for precisely this purpose. Just call it after the
new mode is set.
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than refactoring all our init code only to have it go away when
we remove UMS, this patch adds a build time flag to allow the driver to
assume KMS support.
With this flag active, the driver will not request that I/O or MEM be
enabled at probe time, which can allow the server (if other drivers also
cooperate) to run as a non-root user.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Dump some of the audio registers at server startup time.
(II) intel(0): AUD_CONFIG: 0x00000004
(II) intel(0): AUD_HDMIW_STATUS: 0x00000000
(II) intel(0): AUD_CONV_CHCNT: 0x00000000
(II) intel(0): VIDEO_DIP_CTL: 0x20000600
(II) intel(0): AUD_PINW_CNTR: 0x00000040
(II) intel(0): AUD_CNTL_ST: 0x00002000
(II) intel(0): AUD_PIN_CAP: 0x00000094
(II) intel(0): AUD_PINW_CAP: 0x004073bd
(II) intel(0): AUD_PINW_UNSOLRESP: 0x80000008
(II) intel(0): AUD_OUT_DIG_CNVT: 0x00000001
(II) intel(0): AUD_OUT_CWCAP: 0x00006211
(II) intel(0): AUD_GRP_CAP: 0x00000004
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
The 965 docs note, and it's probably the case on 915 as well, that the
2x2 subspans are read as a unit, even if the bottom row isn't used. If
the address in that bottom row extended beyond the end of the GTT, a
fault could occur.
Thanks to Chris Wilson for pointing out the problem.
Only apply on G4X with SR01 bit5 workaround for VGA plane disable, and
restore behavior back for other chips to make sure other modes got disabled
too.
For bug #17235, #19715, #21064, #23178
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We only set up one sampler, because all of our sampling is the same. By
using a non-zero index for the other two samplers, we'd dereference (likely)
zeroed data, resulting in using NEAREST filtering. This was a regression in
40671132cb which incidentally switched from
having 6 samplers to 1.
Bug #22895, #19856
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing because of
the incorrect DVO offset in LVDS panel data entry.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Chris Wilson
Daniel Vetter
Daniel Vetter
Jesse Barnes
Matthias Hopf
Li Peng
Dave Airlie
Eric Anholt
Robert Hooker
Mario Kleiner
Carl Worth
Adam Jackson
Keith Packard
Tobias Doerffel
Gaetan Nadon
Kristian Høgsberg
Daniel Kahn Gillmor
Rémi Cardona
Thomas Arnhold
Zhenyu Wang
Zhao Yakui
Albert Damen
Zou Nan hai
Wu Fengguang
Kristian Høgsberg