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>
This removes the explicit transform disabling code in drm_set_mode_major.
Without a fixed X server, transforms will still be broken, but even a fixed
X server can't work around this driver bug.
Signed-off-by: Keith Packard <keithp@keithp.com>
This improves aa10text performance from 74k to 569k on my 855 laptop.
This also causes my 865 to hang on aa10text like it does on rgb10text,
thanks to actually hitting render accel.
This lets the driver allocate a nice idle buffer object instead of a
busy one, reducing runtime of firefox-20090601 on my G45 from 50.7 (+/- .41%)
to 48.4 (+/- 1.1%).
This synchronizes the X EDID data with the kernel EDID data each time the
kernel data may have changed. Otherwise, X ends up stuck with the first EDID
data it sees, failing to accomodate to different monitors.
Signed-off-by: Keith Packard <keithp@keithp.com>
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
SHM is now shm.h instead of shmstr. Requires definition of ShmFuncs that's
not exported by the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The two shared i830_composite.c, so giving i830 atomic batch support
triggered anger about starting i830's atomic area while in i915's atomic
area. Instead, split the emit-a-primitive stuff from the state emission.
scrn->fbOffset may be changed when binding objects to the aperture during
server initialization or VT enter. This was accidentally removed when the
NoAlloc option was eliminated.
Signed-off-by: Keith Packard <keithp@keithp.com>
Without kernel support and explicit knowledge about where in the ring the
last rendering operation for a specific pixmap was, we must synchronize with
any outstanding rendering before accessing a pixmap which does not have a
buffer object.
Signed-off-by: Keith Packard <keithp@keithp.com>
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard <keithp@keithp.com>
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for us.
Binding objects is done in one of two ways. For GEM buffer objects, we use
dri_bo_pin. For GART allocated memory, we bind that to the GART.
GEM requires GTT space to map objects. Under KMS, the kernel driver has
already provided all available GTT space to GEM, so the X server need not do
anything.
Signed-off-by: Keith Packard <keithp@keithp.com>
For non-DRM environments, the screen pixmap will be GART allocated memory
and not a libdrm buffer object and so uxa will only use devPrivate.ptr to
find the associated memory. Make sure devPrivate.ptr is set each time the
framebuffer is allocated so that uxa will be able to draw to it.
Signed-off-by: Keith Packard <keithp@keithp.com>
KMS mode does not call I830AccelMethodInit as that does the user
modesetting initialization (yes, it was misnamed), but that means that the DRI option
was ignored. Create a new i830_check_dri_option function to do the option
detection, then remove that from I830AccelMethodInit, which is renamed
i830_user_modesetting_init to reflect what it actually does.
Signed-off-by: Keith Packard <keithp@keithp.com>
This removes yet another 'debugging' option that hasn't seen real use in a
long time, and wasn't supported under KMS in any case.
Signed-off-by: Keith Packard <keithp@keithp.com>
The overcommit of address space combined with these buffers hitting SW
fallbacks all the time means that we're probably better off telling the
application "no" instead of likely silently failing later.
Bug #22601.
Currently we implemented basic sdvo lvds function,
But except for sdvo lvds fixed mode, we can not switch
to other modes, otherwise display get black. The patch
intends to work for all modes whose HDisplay and VDisplay
are lower than fixed mode.
Signed-off-by: Ma Ling <ling.ma@intel.com>
The bigrequests limit isn't present in current X servers (tested using
textured video on a 965 with both image and window at 2048x2048 on a
1920x1200 display, and image at 2048x2048, window at 1024x1024).
Remove the artificial limit, enabling full-screen HD video when
rotated.
When not using DRI, the screen pixmap is not in a bo, and so the usual
enable/disable access functions don't adjust the pixmap devPrivate field,
leaving it to the frame buffer allocation code to assign this correctly.
During mode setting and fb resizing, FB access is disabled, and the
screen pixmap devPrivate is stashed away by xf86EnableDisableFBAccess,
to be restored when FB access is turned back on. This means that we have to
set the pixmap devPrivate.ptr (in case xf86EnableDisableFBAccess doesn't
do this), along with storing the address in the scrn->pixmapPrivate field.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
After failing to become DRM master, the X server dies attempting to close
the master fd during free:
(EE) intel(0): [drm] failed to set drm interface version.
(EE) intel(0): Failed to become DRM master.
(EE) intel(0): failed to get resources: Bad file descriptor
(EE) intel(0): Kernel modesetting setup failed
Backtrace:
0: X(xorg_backtrace+0x3b) [0x8133a3b]
1: X(xf86SigHandler+0x55) [0x80c7945]
2: [0xb805d400]
3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b4bfcc]
4: X(xf86DeleteScreen+0x6b) [0x80d465b]
5: X(InitOutput+0x548) [0x80b0158]
6: X(main+0x1cb) [0x807220b]
7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7d107a5]
8: X [0x8071881]
Saw signal 11. Server aborting.
ddxSigGiveUp: Closing log
ddxSigGiveUp: re-raising 11
Segmentation fault
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The DRI2 interface was changed to support both old and new drivers in an
API/ABI compatible fashion. This change syncs the intel driver with the new
version of the DRI2 API.
Signed-off-by: Keith Packard <keithp@keithp.com>
When playing a movie that is clipped on its left and right edges the Xorg
server will SEGV sometimes. This is because the intel driver ignores the
clipping info when it copies the planes out of the XV data.
The check for the optimised copy was wrong to ignore the width required.
Which leads to too much data being copied by the memcpy. It the source buffer
happens to end exactly on a page boundary the server will SEGV.
As we reviewed the code we checked the calculation of src1, src2 and src3.
The patch includes additional comments to make it clear what the elements of
the calculation are.
This bug exists in git head and we also see it in 2.4.1.
Barry
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since the scratch pixmap header will be re-used after allocation, we
need to clear its bo attachment when we stop using it, otherwise a later
user will use a bogus bo.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
To slightly clean up the implementation of i830_update_polyphase_coeffs,
introduce the two small helper functions i830_limit_coeff and
i830_store coeffs_in_overlay_regs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
- also ensure that the most significant byte is zero
- while I was looking at the code, add the Overlay suffix to
SetPortAttribute like in the textured case.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bug #19578. We should set private intel_crtc state according
to current, as fail to do so pipe A needs active won't be taken
care of. Also make sure pipe swap operation always set during
VT switch.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
If i915 module has already been loaded and kms check is true,
it would be nice to load fbcon module too.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
The only things we try to pin in KMS mode are the cursor objects and
front buffer, and those are taken care of by the kernel anyway, so we
shouldn't even bother trying to pin them (well, not entirely true,
XvMC tries to pin as well, but it needs work w/KMS anyway).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This is what's expected by the server, and allows the EDID for example
to be exported in the KMS case.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The KMS side was correct, but the UMS patch was broken. We need to use
the DVO timing block of the LFP data to get the timing, not the
fp_timing block.
Fixes fdo bug #22529.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch enables 2D composite on IGDNG. IGDNG requires
new compiled shader programs for Gen5 and some command changes.
The most notable is the layout of vertex element has changed,
but we tried to keep it as origin to not change shader programs.
Also vertex buffer state requires end address of vertex buffer
instead of origin max index.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Commit 1eec83a203, which added the new
SwapbuffersWait option, didn't actually include the code which used it. So
add a test to DRI2's CopyRegion call, only emitting the scanline wait
command if the swapbuffers_wait option is set.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
These chips require physical address for XvMC surface, which
is not available in KMS case. Instead of crashing X, disable it now.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Otherwise we may end up returning a false positive if some other output & crtc
are on, but not the one in question, again leading to hangs.
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Now that swapbuffers does a scanline wait to avoid tearing, it's
important to take into account the CRTC status to avoid hangs. If we
do a scanline wait when the CRTC is off (due to DPMS for example) we'll
hang the GPU. So add some code to check the CRTC DPMS status to the
i830_covering_crtc function, returning NULL if none of the covering
CRTCs are actually active. KMS vs UMS logic is hidden in new i830*
functions, cleaning up both DRI2 & video paths a bit.
Fixes fdo bug #22383.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Until we get triple buffering, we'll want this so users can avoid taking a
performance hit on apps that render slower than the refresh rate.
Fixes fdo bug #22234.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Apparently the proper way to do this is to use the LFP data pointer block to figure out the LFP data block entry size, then use that plus the panel index to calculate an offset into the LFP data block array.
Fixes fdo bug #19450.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Don't the change the blank/vsync width while doing LVDS scaled modes.
And use the border instead of border minus one.
At the same time, make sure the horizontal border and hsync are even for
the LVDS that works in dual-channel mode. So both horizontal border and hsync
start are also changed to be even, even for the LVDS in single-channel
mode.
https://bugs.freedesktop.org/show_bug.cgi?id=20951
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
We detect TV connect status by setting DAC voltage level override
values as 0.7 voltage for DAC_A/B/C. The corresponding 2-bits shold be 0x2,
In order correctly to set last bit as 0, at first we must clean it.
It fixed freedesktop.org bug #21204
Signed-off-by: Ma Ling <ling.ma@intel.com>
We detect HDMI output connection status by writing to HOT Plug Interrupt
Detect Enable bit in PORT_HOTPLUG_EN. The behavior will generate an specified
interrupt, which is caught by audio driver, but during one detection driver
set all Detect Enable bits of HDMIB, HDMIC and HDMID, which generate wrong
interrupt signals for current output, according to the signals audio driver
misunderstand device status. The patch intends to handle corresponding output
precisely.
It fixed fredesktop bug #21371
Signed-off-by: Ma Ling <ling.ma@intel.com>
Add quirk to solve issue with black screen and hang occuring after closing the
lid with attached external monitor, on Dell Mini.
Fixes fdo bug #21960.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
When the slave address is found for the SDVO port, the SDVO device will
be initialzied.
When the slave address is not found for the SDVO port, it will return
the slave address by using the following flowchart:
a. If the SDVO device info is found for another SDVO port, it will return
the slave address that is not used. For example: if 0x70 is used, then 0x72
is returned.
b. If no SDVO device info is found for another SDVO port, it will return
0x70 for SDVOB and 0x72 for SDVOC.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The general definition block contains the child device tables, which include
the child device info. For example: device slave address, device dvo port,
device type.
We will get the info of SDVO device by parsing the general definition blocks.
Only when a valid slave address is found, it is regarded as the SDVO device.
And the info of DVO port and slave address is recorded.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The size of general definition block varies on different platform/machines.
In such case the number of child device is also different.
And it will be better to get the number of child device in general definition
block dynamically.
The number of child device can be calculated by the following formula:
(block_size - block_header_size) /
sizeof( struct child_device_config)
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Under KMS, directRenderingType will get set to DRI_NONE during driver
initialization. When the first batch buffer is allocated, as
directRenderingType is DRI_NONE, the GEM bufmgr would get trashed as
intel_batch_init called a fake-bufmgr specific function.
Signed-off-by: Keith Packard <keithp@keithp.com>
If we don't find xext.pc, disable xvmc instead of failing configure
Also add dependencies on xfixes and dri2proto (src/xvmc/dri2.h includes
<X11/extensions/Xfixes.h> and <X11/extensions/dri2tokens.h>).
In some configurations, it's possible to wait for a scanline outside of
a given CRTC range. Make sure that can't happen to fix multihead cases
with dead space.
Fixes fdo bug #22203.
Signed-off-by: Lukasz Kurylo <Lukasz.Kurylo@gmail.com>
Use pci resource size instead, which will get the correct MMIO range.
New chipset uses obviously larger MMIO range.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Desktop and mobile version of new chipsets are added.
Also do memory config like Intel 4 series chipset.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
GEM pads pixmaps to 512 byte stride and backs them with a kernel side
buffer objects. We typically don't render out of glyph pictures, so
we're incurring a lot of overhead per glyph by allocating a GEM pixmap
per glyph. By looking at the usage hint, we can fall back to
fbCreatePixmap for pixmaps backing glyph pictures, which gives us
a nice tight malloced pixmap. The fast path for text rendering is
compositing from the glyph cache pixmap to the destination, which
shouldn't be significantly affected.
Quick bit of testing:
(firefox-20090601)
xlib-rgba-before 384512.49: 1.01x
xlib-rgba-after 389633.94: 1.00x
The difference being within the margin of error for the benchmark.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Daniel Vetter
Jesse Barnes
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
Dave Airlie
Matthias Hopf
Zou Nan hai
Wu Fengguang
Kristian Høgsberg
Krzysztof Halasa
Xiang, Haihao
Peter Hutterer
Barry Scott
ling.ma@intel.com
Simon Farnsworth
Zhenyu Wang
Alan Coopersmith
Bryce Harrington
Li Peng
Julien Cristau
Lukasz Kurylo
root