| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
v2: Fix "orignal" too (review feedback by ajax, change by anholt)_
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
XRender defines this, GL really doesn't like it.
kwin 4.x and qt 4.x seem to make this happen for the
gradient in the titlebar, and on radeonsi/r600 hw
this draws all kinds of wrong.
v2: bump this up a level, and check it earlier.
(I assume the XXXX was for this case.)
v3: add same code to largepixmap paths (Keith)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This will let us eliminate the pixmap types shortly
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Just embed the large elements in the regular pixmap private and
collapse the union to a single struct.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
There's no reason to waste memory storing redundant copies of the same
pointer all over the system; just pass in pointers as necessary to
each function.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
This enables the assertion that all users of the large pixmap member
are restricted to pixmaps which are actually large.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
glamor_composite_largepixmap_region is given the job of dealing with
compositing between a mixture of large and small pixmaps. However, it
was assuming that the destination pixmap was large and fetching
members of the large structure even for small pixmaps.
This manifested with assertion failures when compositing from a large
pixmap to a small pixmap.
Fixed by using the pixmap size for the destination block size for
small pixmaps.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
glamor_compute_clipped_regions_ext wants to treat small and large
pixmaps uniformly and did that by writing into the large pixmap
union member in small pixmaps to construct something that looks like a
one texture large pixmap.
Instead of doing that, simply allocate the necessary elements locally
on the stack and use them from there.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
For now, this simply fetches the large member of the pixmap private.
It will be changed to assert that the pixmap is large once bugs
related to that have been fixed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
This is the last function-like macro in glamor_priv.h; change to
static inline like all of the other functions there.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
Paints with textures, using a temporary buffer for overlapping copies
Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy
plane when both objects are in the GPU. Includes copy_window
acceleration too.
v2: Use NV_texture_barrier for non-overlapping copies within the same
drawable
v3: Switch to glamor_make_current
v4: Do overlap check on the bounding box of the region rather than
on individual boxes
v5: Use Eric Anholt's re-written comments which provide a more accurate
description of the code
v6: Use floating point uniform for copy plane bit multiplier. This
avoids an int to float conversion in the copy plane fragment shader.
Use round() instead of adding 0.5 in copy plane. round() and +0.5
end up generating equivalent code, and performance measurements
confirm that they are the same speed. Round() is a bit clearer
though, so we'll use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
|
|
Glamor has a mode where pixmaps will be constructed from numerous
small FBOs. This allows testing of the tiled pixmap code without
needing to create huge pixmaps.
However, the render glyph code assumed that it could create a pixmap
large enough for the glyph atlas. Instead of attempting to fix that
(which would be disruptive and not helpful), I've added a new pixmap
creation usage, GLAMOR_CREATE_NO_LARGE which forces allocation of a
single large FBO.
Now that we have pixmaps with varying FBO sizes, I then went around
and fixed the few places using the global FBO max size and replaced
that with the per-pixmap FBO tiling sizes, which were already present
in each large pixmap.
Xephyr has been changed to pass GLAMOR_CREATE_NO_LARGE when it creates
the screen pixmap as it doesn't want to deal with tiling either.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
If the repeat direction only has one block, then we need to set the
dx/dy to cover all the extent. This commit also silence some compilation
warnings.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
|
If the source and destination are the same pixmap/fbo, and we
need to split the copy to small pieces. Then we do need to
consider the sequence of the small pieces when the copy area
has overlaps. This commit take the reverse/upsidedown into
the clipping function, thus it can generate correct sequence
and avoid corruption self copying.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
|
The simplest way to support large pixmap's self compositing
is to just clone a pixmap private data structure, and change
the fbo and box to point to the correct postions. Don't need
to copy a new box.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
|
This commit implement almost all the needed functions for
the large pixmap support. It's almost complete.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
|
Now we start to enable glamor_composite on large pixmap.
We need to do a three layer clipping to split the dest/source/mask
to small pieces. This commit only support non-transformation and
repeat normal case.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
|
Added infrastructure for largepixmap, this commit implemented:
1. Create/Destroy large pixmap.
2. Upload/Download large pixmap.
3. Implement basic repeat normal support.
3. tile/fill/copyarea large pixmap get supported.
The most complicated part glamor_composite still not implemented.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
