r xf86_crtc_rotate_coord_back nor
xf86_crtc_rotate_coord are a perfect fit for
xf86_crtc_transform_gpu_cursor_position. The fixed
xf86_crtc_rotate_coord might kind of work, but might require inverting
the rotation sense.
[0] BTW, do we really need two functions? The method used in
xf86_crtc_transfor
On 07/09/16 08:43 PM, Hans de Goede wrote:
> On 07-09-16 03:21, Michel Dänzer wrote:
>> On 06/09/16 08:31 PM, Hans De Goede wrote:
>>> xf86_crtc_rotate_coord_back should be the exact inverse operation of
>>> xf86_crtc_rotate_coord, but when calculating x / y for 90
ate_coord_back here, though actually I'm not sure why
it wouldn't work as is? What's the problem?
Patches 1, 2, 4 & 7 are
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
it's kind of the other way around:
xf86_crtc_transform_cursor_position just happens to still work with your
change because usually cursor_info->MaxWidth == cursor_info->MaxHeight .
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
;vtSema &&
> xorg_list_is_empty(>pixmap_dirty_list) &&
> +if (infoPtr->pScrn->vtSema &&
If you remove the check for empty pScreen->pixmap_dirty_list already in
this patch, we will attempt to use HW cursors on PRIME slave outputs,
but it won't work correctly, right?
infoPtr->MaxHeight) {
> if (infoPtr->UseHWCursor)
> return infoPtr->UseHWCursor(pScreen, cursor)
> else
> return TRUE;
> }
>
> As my comment came late and is beautifying only, feel free to ignore it.
If you do end up cha
gt; We can chat about how things are going at XDC, of course.
>
> This is only a proposal; let's try to generate some rough consensus in
> the next day or two on a final schedule.
This looks quite aggressive, but no objections from me.
--
Earthling Michel Dänzer |
On 06/09/16 01:08 PM, Kenneth Graunke wrote:
>
> For that matter, why not delete DRI2 support entirely at this point?
Some things (such as the VA-API backend for Intel GPUs IIRC, or the
amdgpu-pro OpenGL driver in current releases) still only support DRI2.
--
Earthling Michel
fdef GLAMOR in pageflip.c, it would be more consistent to do the same
in driver.h. But either way, with the bugzilla tag fixed,
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.c
(cursor->bits->width <= infoPtr->MaxWidth) &&
>> - (!infoPtr->UseHWCursor || (*infoPtr->UseHWCursor)
>> (pScreen, cursor)) {
>> + xf86CheckHWCursor(pScreen, cursor, infoPtr)))
Apologies, this was meant for the amd-gfx mailing list.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
From: Michel Dänzer <michel.daen...@amd.com>
Only copy once for each time we update the corresponding scanout pixmap.
This can significantly reduce the bandwidth usage when there are
frequent updates to the screen pixmap.
This initial implementation only works when both the master and
On 01/09/16 10:24 AM, Michel Dänzer wrote:
> On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
>> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie <airl...@gmail.com> said:
>>> On 31 August 2016 at 22:10, Hans de Goede <hdego...@redhat.com> wrote:
>&
the top. i should assume your display is likely
> composited right? which means it may be that that area is being drawn
> regardless of where glxgears is. compositor is drawing it.
>
> good luck with this one. i have an idea that'd make it better but not perfect.
> y
On 31/08/16 05:56 PM, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
> include/scrnintstr.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --
From: Michel Dänzer <michel.daen...@amd.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
include/scrnintstr.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index 5330714..52e8382 100644
-
On 25/08/16 10:38 PM, Корень Зла wrote:
> Can u code Wayland plagin or nativley support of Wayland t X.org server?
Already done, look up Xwayland.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa an
ong b/c I haven't seen anyone else have this
> problem through internet search.
> I'm using the main window of my application for the parameter
> & I'm using DefaultGC() for my parameter
Please provide the exact code you're running, and the corresponding Xorg
log files.
--
Earthl
Adding Marek and Nicolai, maybe they have some feedback from a GL
(driver) perspective.
On 23/08/16 10:41 AM, Dave Airlie wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> [airlied: rebased onto master -
> I left WO alone as it's more like the GL interface
> revi
On 18/08/16 09:54 AM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Fixes shader compile failure:
>>
>> Failed to compile VS: 0:13(43): error: `pos' undeclared
>>
On 20/08/16 01:53 PM, Eric Anholt wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> On 18/08/16 11:09 PM, Alex Deucher wrote:
>>> On Thu, Aug 18, 2016 at 5:42 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>>> From: Michel Dänzer <michel.d
On 22/08/16 12:53 PM, Qiang Yu wrote:
> Signed-off-by: Qiang Yu <qiang...@amd.com>
> Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
[...]
> @@ -588,8 +594,11 @@ ms_present_flip(RRCrtcPtr crtc,
> if (!event)
> return FALSE;
>
> +DebugPres
;\t\tms:fa %lld c %d\n", (long long)
> flipdata->event->event_id, flipdata->flip_count));
Please preserve this DebugPresent call (minus flipdata->flip_count).
With that (and the copy & paste issue Daniel Martin pointed out fixed,
patches 3 & 4 are
Reviewed-by: Mich
hare with DRI2
> modesetting: move ms_do_pageflip to pageflip.c
> modesetting: move common page flip handle to pageflip.c
> modesetting: add DRI2 page flip support
> modesetting: exclude DRI2 and prensent page flip
Please squash patch 5 into patch 4.
--
Earthling Michel Dänzer
On 19/08/16 04:57 PM, Emil Velikov wrote:
> On 19 August 2016 at 03:09, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 19/08/16 11:02 AM, Yu, Qiang wrote:
>>>
>>> Each point of the patch set is not broken. Patches are arranged like
>>> this to show how I
ing driver.
Note that I'm not saying you need to address that as part of this
series, just that the comment above shouldn't mention SW cursors.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 18/08/16 11:09 PM, Alex Deucher wrote:
> On Thu, Aug 18, 2016 at 5:42 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> This can significantly speed up at least some CopyPlane cases, e.g.
>> indirectly
>>
>> SW cursors cannot work correctly with page flipping. For that reason,
>> xf86-video-ati/amdgpu disable page flipping while there's an SW cursor.
> [yuq] why? Is the problem in kernel or xserver?
The latter, due to the way SW cursor works. There's a fundamental (an
the issues fixed by patch 4. So
maybe patch 4 should be squashed into patch 3.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org:
was no previous DRI2 page flipping support in modesetting?
That's correct.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.
On 15/08/16 11:18 PM, walter harms wrote:
> Am 15.08.2016 11:43, schrieb Michel Dänzer:
>>
>> diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c
>> index 3501a0d..82e040a 100644
>> --- a/glamor/glamor_copy.c
>> +++ b/glamor/glamor_copy.c
>> @
From: Michel Dänzer <michel.daen...@amd.com>
This can significantly speed up at least some CopyPlane cases, e.g.
indirectly for stippled fills.
v2:
* Make temporary pixmap the same size as the destination pixmap
(instead of the destination drawable size), and fix coordinate
parameters
; modesetting: remove redundent pixmap destroy
Patches 2, 4 & 5 are
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Patch 6 was already submitted by Hans de Goede:
https://patchwork.freedesktop.org/patch/105351/
--
Earthling Michel Dänzer |
py and shove it over the USB.
> + * also for sw cursors.
> + */
SW cursors cannot work correctly with page flipping. For that reason,
xf86-video-ati/amdgpu disable page flipping while there's an SW cursor.
--
Earthling Michel Dänzer
long long) seq));
Might be nice to move this debugging output to ms_present_flip instead
of removing it completely.
With that fixed, this patch is
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software e
s that
intentional, i.e. is it okay for others to push glamor changes which are
ready, or should we always get in touch with Eric first?
> * Alan Coopersmith - security
> * Peter Hutterer - input
> * Adam Jackson - xfree86 backend
> * Keith Packard- misc
> * Michel Dä
server
>4d58611..92b3cd3 master -> master
Unfortunately, this broke two XTS tests:
xts5@xlib9@xgetimage@7
xts5@xlib9@xgetsubimage@7
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
.)
>
> As user i can say it is helpful to have a starting point.
From my experience with helping users, it's a horrible starting point:
Bloated with lots of stuff most of which the majority of users will
never need. For the most common case where one just wants to tweak some
driver opt
From: Michel Dänzer <michel.daen...@amd.com>
Fixes shader compile failure:
Failed to compile VS: 0:13(43): error: `pos' undeclared
0:13(14): error: operands to arithmetic operators must be numeric
0:13(13): error: operands to arithmetic operators must be numeric
Program source:
#
think things succeeded even when we'd generated
> an error.
>
> With that fixed, the test code's failure to swap the window id would
> make dixLookupWindow (rightly) throw BadWindow.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.
swaps(>length);
144 rc = SProcXIQueryPointer(_request);
145 assert(rc == error);
146
147 if (rc == BadDevice)
148 assert(client_request.errorValue == req->deviceid);
149 }
--
Earthling Michel Dänzer | http://www.amd.
t longer term, maybe we should just remove Xorg -configure? Does
it serve any useful purpose anymore? I know it causes quite a lot of
trouble for users and those trying to help them...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 19.07.2016 02:49, Adam Jackson wrote:
> On Tue, 2016-07-12 at 12:39 +0900, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> This can significantly speed up at least some CopyPlane cases, e.g.
>> indirectly for stippled fills.
From: Michel Dänzer <michel.daen...@amd.com>
This can significantly speed up at least some CopyPlane cases, e.g.
indirectly for stippled fills.
v2:
* Make temporary pixmap the same size as the destination pixmap
(instead of the destination drawable size), and fix coordinate
parameters
if test "x$XORG" = xyes; then
> + GLAMOR=yes
> + fi
> + if test "x$XEPHYR" = xyes; then
> + GLAMOR=yes
> + fi
> +fi
What about Xwayland?
--
Earthling Michel Dänzer | http://www.amd.com
Libre sof
ely used outside of X.
I agree, though at the very least, distributors would need to ensure
that Xorg and its drivers don't end up linked against different
libpciaccess SONAMEs.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 09/08/16 10:21 AM, Michel Dänzer wrote:
> On 05/08/16 11:38 AM, Michel Dänzer wrote:
>>
>> Humble ping — https://bugs.freedesktop.org/show_bug.cgi?id=97154 is
>> accumulating duplicates...
>
> A third duplicate report has come in.
>
> Is there any problem wit
16_tdomain;
> +uint32_tdomain;
This change breaks ABI, so as is it would require bumping the library
SONAME (which is painful and thus generally discouraged from a
downstream POV).
--
Earthling Michel Dänzer | htt
On 05/08/16 11:38 AM, Michel Dänzer wrote:
>
> Humble ping — https://bugs.freedesktop.org/show_bug.cgi?id=97154 is
> accumulating duplicates...
A third duplicate report has come in.
Is there any problem with my fix? If not, can I just push it myself, so
users of the modesetting drive
r); /* TimerFree will call
> TimerCancel() */
> xorg_list_del(_vblank->list);
> free (fake_vblank);
> break;
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www
r
> - installed the nonfree firmware
> - kernel radeon exceptions can be found in the /var/log/messages (see below)
The GPU hangs. I'm afraid your best bet is to try newer upstream
versions of the kernel and Mesa.
--
Earthling Michel Dänzer | http://www.
video-ati Git master works better; there was recently a change
which reduced compositing overhead, but I'm afraid it's unlikely to make
a big difference with EXA.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Me
Humble ping — https://bugs.freedesktop.org/show_bug.cgi?id=97154 is
accumulating duplicates...
Or may I just push this myself?
On 02.08.2016 10:01, Michel Dänzer wrote:
>
> Hi Keith / Adam,
>
>
> The following changes since commit c833c0866f2f8f829185667efe3d6dfa5979a9e8:
ot being refreshed resulting in a nearly scrambled desktop
> after some time of use with several graphical programs. I also
> noticed some similar problems with the terminal.
Please provide the corresponding Xorg log file.
--
Earthling Michel Dänzer |
On 04.08.2016 03:18, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> I'm afraid that's not feasible: An additional optimization will be to
>> never flush for clients which aren't sharing any buffers with the server
>> via DRI.
On 03.08.2016 01:12, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> 2. By passing the ClientPtr to FlushCallbacks, drivers can completely
>>eliminate unnecessary flushing of GPU commands by keeping track of
>>whether we're flu
On 03.08.2016 09:51, Michel Dänzer wrote:
> On 03.08.2016 09:40, Eric Anholt wrote:
>> Michel Dänzer <mic...@daenzer.net> writes:
>>
>>> From: Michel Dänzer <michel.daen...@amd.com>
>>>
>>> This change has two effects:
>>>
>
On 03.08.2016 14:10, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> This can indeed only avoid the problem by accident, since there's no
>> guarantee that the primary output is even connected.
>
> Actually, he used the RRFirstOutput func
From: Michel Dänzer <michel.daen...@amd.com>
We were asserting that these were called before from other places, but
that isn't always the case, e.g. during server shutdown.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96951
Reported-and-Tested-by: Tod Jackson <tod.jack...@
From: Michel Dänzer <michel.daen...@amd.com>
Easier than dealing with it in all paths that can end up here during
server shutdown.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
present/present.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --g
the problem by accident, since there's no
guarantee that the primary output is even connected.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Descript
On 03.08.2016 09:40, Eric Anholt wrote:
> Keith Packard <kei...@keithp.com> writes:
>
>> Michel Dänzer <mic...@daenzer.net> writes:
>>
>>> From: Michel Dänzer <michel.daen...@amd.com>
>>>
>>> This change has two effects:
>>
On 03.08.2016 09:40, Eric Anholt wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> This change has two effects:
>>
>> 1. Only calls FlushCallbacks when we're actually flushing data to a
&
On 08.07.2016 19:01, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> The unnecessary FlushCallback calls could cause significant performance
> degradation with compositing.
>
> As an example, with the radeon driver using glamor, a gtkperf run us
From: Michel Dänzer <michel.daen...@amd.com>
This change has two effects:
1. Only calls FlushCallbacks when we're actually flushing data to a
client. The unnecessary FlushCallback calls could cause significant
performance degradation with compositing, which is significantly
reduce
changes up to 8bb9d460fbc82ee5d6f87e1d11cfa52f4f3072ee:
xfree86/modes: Handle no palette case better in xf86RandR12CrtcSetGamma
(2016-08-02 09:57:56 +0900)
Michel Dänzer (1):
xfree86/modes: Handle no palette case better
On 29.07.2016 17:51, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Just use the RandR gamma ramp directly.
>
> Fixes random on-monitor colours with drivers which don't call
> xf86HandleColormaps, e.g. modesetting.
Bugzilla: https://bugs.freedes
On 30.07.2016 09:54, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Fixes crash in ScreenInit -> xf86HandleColormaps ->
>> xf86RandR12LoadPalette with drivers which don't ass
On 29.07.2016 01:54, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Without this change, there's no way for a client to explicitly change
>> or destroy an existing event mask entry. Trying to do so as specified
>> above would actually resul
From: Michel Dänzer <michel.daen...@amd.com>
From the Present extension specification:
An event context is associated with a specific window; using
an existing event context with a different window generates
a Match error.
If eventContext specifies an existing event c
From: Michel Dänzer <michel.daen...@amd.com>
Just use the RandR gamma ramp directly.
Fixes random on-monitor colours with drivers which don't call
xf86HandleColormaps, e.g. modesetting.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
hw/xfree86/modes/xf86RandR12.c | 10 +
From: Michel Dänzer <michel.daen...@amd.com>
Fixes crash in ScreenInit -> xf86HandleColormaps ->
xf86RandR12LoadPalette with drivers which don't assign pScrn->pScreen
in ScreenInit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97124
Signed-off-by: Michel Dänzer <mich
From: Michel Dänzer <michel.daen...@amd.com>
From the Present extension specification:
If eventContext specifies an existing event context, then if
eventMask is empty, PresentSelectInput deletes the specified
context, otherwise the specified event context is changed to
select a differe
10:12:44 +0900)
Michel Dänzer (4):
xfree86/modes: Move gamma initialization to xf86RandR12Init12 v2
xfree86/modes: Remove xf86RandR12CrtcGetGamma
xfree86: Hook up colormaps and RandR 1.2 gamma code v6
present
On 28.07.2016 00:02, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> v6:
>> * Handle reallocarray failure in xf86RandR12LoadPalette (Keith Packard)
>
> Yeah, that'll work.
>
> Reviewed-by: Keith Packard <kei...@keithp.com>
T
On 27.07.2016 18:09, walter harms wrote:
> Am 27.07.2016 04:39, schrieb Michel Dänzer:
>> On 26.07.2016 23:25, walter harms wrote:
>>> Am 26.07.2016 11:11, schrieb Michel Dänzer:
>>>>
>>>> diff --git a/hw/xfree86/modes/xf86RandR12.c
>>>&g
On 27.07.2016 00:55, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> +if (randrp->palette_size != palette_size) {
>> +randrp->palette = reallocarray(randrp->palette, palette_size,
>> +
From: Michel Dänzer <michel.daen...@amd.com>
Instead of breaking the former when the driver supports the latter,
hook them up so that the hardware LUTs reflect the combination of the
current colourmap and gamma states. I.e. combine the colourmap, the
global gamma value/ramp and the RandR 1
On 26.07.2016 23:25, walter harms wrote:
> Am 26.07.2016 11:11, schrieb Michel Dänzer:
>>
>> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
>> index 9f93270..5b24ebb 100644
>> --- a/hw/xfree86/modes/xf86RandR12.c
>> +++ b/hw/xfree86/
From: Michel Dänzer <michel.daen...@amd.com>
Instead of breaking the former when the driver supports the latter,
hook them up so that the hardware LUTs reflect the combination of the
current colourmap and gamma states. I.e. combine the colourmap, the
global gamma value/ramp and the RandR 1
From: Michel Dänzer <michel.daen...@amd.com>
RRCrtcGammaSetSize cannot be used yet in xf86InitialConfiguration,
because randr_crtc isn't allocated yet at that point, but a following
change will require RRCrtcGammaSetSize to be called from
xf86RandR12CrtcInitGamma.
v2:
* Bai
From: Michel Dänzer <michel.daen...@amd.com>
present_restore_screen_pixmap's work doesn't need to be done several
times for the same pending flip.
Fixes a crash if the X server quits while a flip is pending, in which
case present_set_abort_flip may be called several times, including when
er.c
> +++ b/hw/xfree86/common/xf86VGAarbiter.c
> @@ -105,7 +105,7 @@ Bool
> xf86VGAarbiterAllowDRI(ScreenPtr pScreen)
> {
> int vga_count;
> -int rsrc_decodes;
> +int rsrc_decodes = 0;
> ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
>
> if (vga_no_a
trouble-shoot it internally.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/a
Out of curiosity, why is pScrn->vgaDev == NULL in this case?
Anyway, the code change looks good to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
On 19.07.2016 23:58, Adam Jackson wrote:
> On Tue, 2016-07-19 at 12:34 +0900, Michel Dänzer wrote:
>> On 19.07.2016 05:29, Adam Jackson wrote:
>>> [...]
>>>
>>> New commits:
>>> commit 8d3a368d8980e37e7e8c57065dc901ce809887c6
>>> Author: Keit
atches to the
amd-...@lists.freedesktop.org mailing list for review before pushing them.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@list
orPos, but in this case more drivers
are affected, including the major ones. This is pretty frustrating and
causing me a waste of time and effort.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
From: Michel Dänzer <michel.daen...@amd.com>
This can significantly speed up at least some CopyPlane cases, e.g.
indirectly for stippled fills.
Reported-by: Keith Raghubar <keith.raghu...@amd.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
The x/yoff deltas fo
From: Michel Dänzer <michel.daen...@amd.com>
The unnecessary FlushCallback calls could cause significant performance
degradation with compositing.
As an example, with the radeon driver using glamor, a gtkperf run using
default parameters (100 iterations of every test) takes:
(numbers w
From: Michel Dänzer <michel.daen...@amd.com>
Fixes incorrect clipping for redirected windows which don't happen to be
located at the top left corner of the screen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96742
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
On 28.06.2016 18:50, Alexander E. Patrakov wrote:
> 28.06.2016 13:22, Michel Dänzer пишет:
>> This change checks for pixels with alpha == 0 and any non-alpha component
>> != 0. If any such pixel is found, the data is assumed to be
>> non-premultiplied and fixed up by multiplyi
From: Michel Dänzer <michel.daen...@amd.com>
Some games incorrectly use non-premultiplied ARGB cursor data, presumably
because that's what Windows uses. On some hardware (and with SWcursor),
this breaks areas of the cursor which are supposed to be transparent
(and presumably also trans
On 28.06.2016 02:12, Lyude Paul wrote:
> I'm up for this. Better then having to send the same patches for both radeon
> and
> amdgpu to seperate mailing lists :)
I agree, so let's move the xf86-video-ati patch review to amd-gfx as well.
--
Earthling Mich
On 24.06.2016 23:16, Christopher Cramer wrote:
> On Fri, Jun 24, 2016 at 11:15:05AM +0900, Michel Dänzer wrote:
>> Does the attached patch fix this?
>
> Well, it doesn't die with an assertion failure anymore.
Thanks for testing the fix, submitting it for upstream inclusion.
>
From: Michel Dänzer <michel.daen...@amd.com>
Fixes crash with Xinerama enabled, which disables RandR.
Fixes: https://bugs.debian.org/827984
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 2 +-
src/radeon_kms.c | 21 -
2 f
creenResources
> (screen=0x563fb3b30ef0) at ../../../../hw/xfree86/modes/xf86Crtc.c:716
> #9 0x563fb2c75abe in dix_main (argc=7, argv=0x7ffd5dd6af98,
> envp=) at ../../dix/main.c:225
> #10 0x7fa75f9015f0 in __libc_start_main (main=0x563fb2c5ff60 ,
> argc=7, argv=0x7ffd5dd6af98, in
On 23.06.2016 04:58, Emil Velikov wrote:
> On 22 June 2016 at 04:12, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Instead of breaking the former when the driver supports the latter,
>> hook them up so that th
From: Michel Dänzer <michel.daen...@amd.com>
Instead of breaking the former when the driver supports the latter,
hook them up so that the hardware LUTs reflect the combination of the
current colourmap and gamma states. I.e. combine the colourmap, the
global gamma value/ramp and the RandR 1
This is a heads up that we'll be using the amd-...@lists.freedesktop.org
mailing list for xf86-video-amdgpu patch reviews from now on.
Any opinions on whether we should do the same for xf86-video-ati
patches, or continue using this list for that?
--
Earthling Michel Dänzer
501 - 600 of 2518 matches
Mail list logo
