| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Since the UMS code has all been removed.
|
|
In preparation for a new snapshot.
|
|
We plan to collect real release notes before the 2.10.0 release.
|
|
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 b9b159c49854d8d9d2207946bb583537bb0d48d6 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>
|
|
Should have been in libdrm to begin with.
|
|
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This modification is redundant since the routing is done in the blend
unit anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In commit e581ceb, I modified the shader generation to accommodate mixed
textures and solids but missed applying the new computed sampler for the
mask.
References:
Bug 23803 [bisected i915] gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Bug 25031 rendering and color corruption since 14109abf
http://bugs.freedesktop.org/show_bug.cgi?id=25031
Bug 25047 [945GM bisected] rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
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>
|
|
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>
|
|
Avoid mapping the glyph cache back to the cpu by allocating temporary
buffer objects to store the glyph pixmap and blit to the cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Simple warnings for unused variables and C99-style declarations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now that the INSTALL file is generated.
Allows running make maintainer-clean.
|
|
Apparently Debian packages were having to manually add these files
back in. Distribute them in the first place like we meant to.
|
|
Automake 'foreign' option is specified in configure.ac.
Remove from Makefile.am
|
|
Add missing INSTALL file. Use standard GNU file on building tarball
README may have been updated
Remove AUTHORS file as it is empty and no content available yet.
Remove NEWS file as it is empty and no content available yet.
|
|
The git generated ChangeLog replaces the hand written one.
Update configure.ac to xorg-macros level 1.3.
Use XORG_DEFAULT_OPTIONS which replaces four XORG_* macros
Update Makefile.am to add ChangeLog target if missing
Remove ChangeLog from EXTRA_DIST or *CLEAN variables
This is a pre-req for the INSTALL_CMD
|
|
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>
|
|
Or else we hit the buggy 1x1 source path and trigger:
rendercheck/mcoords regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25046
caused by the recent commit e581ceb.
|
|
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>
|
|
In the case of x8r8g8b8 and similar where the alpha channel is ignored,
but should be interpreted as being 1, then it is convenient if those bits
are set appropriately in the colour. In order to do so for these formats,
where PIXMAN_FORMAT_A() returns 0 we need to compute the alpha channel
width as the remaining bits instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit a851139c2141f6da370186148f2836e18b2acf83.
It broke the build, and I don't see why we should be supporting this
anyway.
Conflicts:
configure.ac
src/Makefile.am
|
|
I guess this is the sort of failure due to rebase-happiness that makes
Linus yell at us for rebasing.
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
It's poor style, and has confused new developers.
|
|
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>
|
|
DEBUGFLAGS wasn't used anywhere and the configure switch is useless.
"CFLAGS=-g ./configure" does the same thing and actually works.
PKG_CHECK_MODULES already calls AC_SUBST, no need to do it twice.
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This avoids a crash when an XRenderComposite call is made with a
-1 value for width/height, (which apparently compiz's gtk-window-
decorator likes to do). Fixes bug:
X crashes in uxa_acquire_pattern when logging in (gdm)
http://bugs.freedesktop.org/show_bug.cgi?id=24724
Signed-off-by: Albert Damen <albrt@gmx.net>
Reviewed-by: Carl Worth <cworth@cworth.org>
|
|
Bug #24396.
|
|
v2: Incorporate comments from Jamey on device name handling and extension
detection.
|
