From: Michel Dänzer <michel.daen...@amd.com>
This can happen when a module fails to load:
Program received signal SIGSEGV, Segmentation fault.
UnloadModule (_mod=0x559d9280) at
../../../../hw/xfree86/loader/loadmod.c:848
848 name = mod->VersionInfo->modname;
t;);
> -#endif
> -
> if (DRIExtensionInit() &&
> -#ifdef XF86DRI_EVENTS
> -EventType && ScreenPrivateIndex != -1 &&
> -#endif
> (extEntry = AddExtension(XF86DRINAME,
> XF86DRINumberEvents,
&g
On 26/01/17 06:47 AM, Michael wrote:
> Hello,
>
> On Wed, 18 Jan 2017 11:24:03 +0900
> Michel Dänzer <mic...@daenzer.net> wrote:
>
>>>>> The Creator is weirder - it's got what Sun calls '3dRAM' - little ALUs
>>>>> built into the memory chips whi
ere "[PATCH amdgpu]" is
ambiguous (because the same list is also used for reviewing kernel
driver and libdrm patches).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
ere the core EXA code is in full
control of managing "offscreen" (i.e. GPU accessible) memory. There are
"mixed" and "driver" modes, providing increasing levels of control over
this to the driver. See exa/{exa_driver,exa_migration_
Stop.
make[3]: Leaving directory '/home/daenzer/src/xorg-git/xserver/build-amd64/test'
Looks like -L/usr/local/lib worked for libxservertest_la_DEPENDENCIES,
but doesn't for tests_DEPENDENCIES.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthus
[ Re-adding the xorg-devel list to Cc ]
On 12/01/17 02:01 AM, Michael wrote:
> On Tue, 10 Jan 2017 16:46:35 +0900
> Michel Dänzer <mic...@daenzer.net> wrote:
>> On 09/01/17 07:36 AM, Michael Lorenz wrote:
>>> From: Michael Lorenz <macal...@netbsd.org>
>>>
>
>
Unfortunately, testing reveals that this doesn't work correctly in
general when exaGlyphs is called with maskFormat == NULL, I suspect
because pDst->format may not have any alpha bits here in that case. This
results e.g. in
Any takers?
In the absence of a negative review, I'll push this next week, since
more people are running into this.
On 28/11/16 10:54 AM, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> We are no longer using the present_flip_queue list only for presen
e I don't think composite
operations to 1bpp destinations can ever be accelerated:
if (PICT_FORMAT_BPP(format) == 1)
format = PICT_a8;
If so, the local variable format could be eliminated in favour of using
pDst->format directly.
--
Earthling Michel Dänzer |
server" (which in the common case of a laptop with 2 GPUs just means
"the other GPU"), or DRI_PRIME=[udev device identifier] selects a
specific GPU.
It would be nice if this could work with GLVND's libGL as well.
--
Earthling Michel Dänzer | http://www.amd.
on this topic, in
particular on which of the above two options would be better.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel
From: Michel Dänzer <michel.daen...@amd.com>
We are no longer using the present_flip_queue list only for presents
which have already been submitted to the driver for page flipping, but
also for those which we are queueing up to be flipped later, marked
with vblank->queued == TRUE
From: Michel Dänzer <michel.daen...@amd.com>
We are no longer using the present_flip_queue list only for presents
which have already been submitted to the driver for page flipping, but
also for those which we are queueing up to be flipped later, marked
with vblank->queued == TRUE
On 02/11/16 01:05 PM, Keith Packard wrote:
>
> I don't know of any more patches that need to hit the code before we
> ship.
Somebody still needs to come up with a fix for the FlushAllOutput
crashes, right?
--
Earthling Michel Dänzer | http://www.amd.
tform_probe(DriverPtr pDriver,
> pAMDGPUEnt = pPriv->ptr;
> pAMDGPUEnt->fd_ref++;
> }
> - pAMDGPUEnt->platform_dev = dev;
>
> xf86SetEntityInstanceForScreen(pScrn, pEnt->index,
> xf86GetNumEntityInstances(pEnt->
These two hunks aren't really
From: Michel Dänzer <michel.daen...@amd.com>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 +++
On 10/10/16 09:19 PM, Hans de Goede wrote:
> Hi Adam, Keith,
>
> Here is a pull-req with 2 prime hw cursor fixes from Michel Dänzer,
> reviewed by me and 1 fix from me reviewed by Keith.
I pushed my fixes, but I'm leaving your fix to Peter or somebody else.
--
Earthling M
t; not
> solve the bug #97880 for me.
The bug report status has been RESOLVED FIXED since September 23rd. If
it's actually not fixed yet, please update the status.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
From: Michel Dänzer <michel.daen...@amd.com>
Prevents the HW cursor from intermittently jumping around when the
cursor image is changed while the cursor is being moved. This is hardly
noticeable in normal operation but can be quite confusing when stepping
through these codepaths in a de
From: Michel Dänzer <michel.daen...@amd.com>
xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens.
Fixes incorrect HW cursor position on PRIME slave screens.
Also hoist the hotspot translation out from xf86ScreenSet/MoveCursor to
xf86Set/MoveCursor, since the hotspot po
On 05/10/16 07:05 PM, Hans de Goede wrote:
> On 05-10-16 11:45, Hans de Goede wrote:
>> On 05-10-16 11:41, Michel Dänzer wrote:
>>> From: Michel Dänzer <michel.daen...@amd.com>
>>>
>>> I wanted to enable HW cursors on PRIME slave screens in our drivers
From: Michel Dänzer <michel.daen...@amd.com>
xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens.
Fixes incorrect HW cursor position on PRIME slave screens.
Also hoist the hotspot translation out from xf86ScreenMoveCursor to
xf86MoveCursor, since the hotspot position is a pr
From: Michel Dänzer <michel.daen...@amd.com>
xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens.
Fixes intermittent incorrect HW cursor position on PRIME slave screens
when switching between cursors with different hotspot positions.
Also hoist the hotspot translation ou
From: Michel Dänzer <michel.daen...@amd.com>
I wanted to enable HW cursors on PRIME slave screens in our drivers, but
noticed that a few things aren't quite right yet.
The series is ordered from the most obvious problem to more subtle ones.
Patches 1 & 2 fix incorrect positioning
From: Michel Dänzer <michel.daen...@amd.com>
Prevents the HW cursor from intermittently jumping around when the
cursor image is changed while the cursor is being moved. This is hardly
noticeable in normal operation but can be quite confusing when stepping
through these codepaths in a de
From: Michel Dänzer <michel.daen...@amd.com>
Fixes make check with out-of-tree builds.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
test/scripts/xvfb-piglit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/scripts/xvfb-piglit.sh b/test/
or even a fix at all.
>But it avoids the crash and the regression here.
I looked into this a little yesterday as well, and was heading towards
pretty much the same solution.
Some cosmetic comments below, but regardless of those, this patch is
Reviewed-and-Tested-by: Michel Dänzer <michel.dae
imes can't.
> And it is potentially interesting for Qemu for the same reasons that
> it is for us (relative input device support).
TBH, I feel like the issues you're having with VirtualBox would be
better dealt with at the virtual GPU hardware level, by making the HW
cursor work reliab
prog = _priv->copy_plane_prog;
> copy_facet = _facet_copyplane;
I'd add the if (!glamor_priv->can_copyplane) inside the existing if
(bitplane). Either way though,
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer |
On 26/09/16 03:53 AM, Eric Anholt wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>> On 23/09/16 09:51 PM, Eric Anholt wrote:
>>>
>>> We do need some concerted effort on actually fixing our rendering bugs
>>> and reenabling the skipped tests. I've sp
ents, now seems like a pretty good time.
I'd say it's about a decade late, seeing as the major distros are about
to switch to Wayland/Mir by default.
> And, as much of that code is in the core server now, we shouldn't see
> huge impacts on the drivers?
I wish. Our drivers have wrappers for a
On 27/09/16 12:40 AM, Eric Anholt wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>> On 26/09/16 11:23 AM, Keith Packard wrote:
>>> Eric Anholt <e...@anholt.net> writes:
>>>
>>>> In talking with ajax, I came around to "just compute the
On 26/09/16 12:01 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> And it should be relatively easy to get that with the existing damage
>> code. Since glamor is only interested in the damage region extents, it
>> can set a DamageRep
make the bounds tracking and scissoring
opt-in in glamor, so drivers for traditional non-tiled renderers (which
presumably don't gain anything from the scissoring) don't have to incur
the cost for nothing.
--
Earthling Michel Dänzer | http
nuck in.
> v3: Switch back to src->depth == dst->depth
>
> Signed-off-by: Eric Anholt <e...@anholt.net>
Regardless of the above, patches 1-3 are
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.
s require an accurate region.
(Such a new damageLevel might even be interesting for compositors as well)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Descriptio
On 23/09/16 09:51 PM, Eric Anholt wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>> On 23/09/16 04:57 PM, Eric Anholt wrote:
>>> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
>>> replicated a bug from last time we did a copy optimization, a
On 23/09/16 07:48 PM, Hans de Goede wrote:
> On 09/23/2016 11:13 AM, Michel Dänzer wrote:
>> On 23/09/16 03:46 PM, Hans de Goede wrote:
>>>
>>> Since this is a fallback which ideally should never get used (all
>>> drivers should call xf86HandleColormaps) I
On 23/09/16 03:46 PM, Hans de Goede wrote:
> On 09/20/2016 04:58 AM, Michel Dänzer wrote:
>
>> If there are other drivers which can't call xf86HandleColormaps for some
>> reason, a better solution would be to combine the per-screen gamma set
>> via pScrn->ChangeGamma
epths don't match, but a copy does
what's expected?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archive
On 23/09/16 11:08 AM, Michel Dänzer wrote:
> On 22/09/16 05:45 PM, Eric Anholt wrote:
>> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
>> replicated a bug from last time we did a copy optimization, and didn't
>> get rendercheck run on it. This is effecti
epths at 16bpp
> + * because r,g,b are allocated to different bits.
> + */
> +&& !(dest->pDrawable->bitsPerPixel == 16 &&
> + dest->pDrawable->depth != source->pDrawable->depth)
So this clause will always be true?
A
On 21/09/16 03:49 PM, Peter Hutterer wrote:
> On Fri, Sep 16, 2016 at 05:26:06PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> If --prefix isn't specified on the command line, $prefix contains "NONE"
>> at this p
On 17/09/16 12:51 AM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Does FlushClient get called after every DamageExtNotify call? Otherwise,
>> some of the GPU flushes performed by DamageFlushDrawable will be wasted,
>> hurting performance.
&
to something
along the lines of:
/* Fallback pScrn->ChangeGamma implementation for drivers which can't
* call xf86HandleColormaps. This will clobber the per-CRTC gamma ramp
* of the CRTC assigned to the RandR compatibility output.
*/
--
Earthling Michel Dänzer
clamping the "numColors" value to 256 in DUMMYLoadPalette.
I suspect it's related to DUMMYScreenInit calling xf86HandleColormaps
with 256 for maxColors. That (and possibly other places) probably needs
to be changed to allow for 1024 entries in colourmaps.
--
Earthling Michel Dänzer
ers were you seeing the wrong order of operations with?
I assume you were testing with patch 2 of the series applied?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Descript
On 16/09/16 06:14 PM, Hans de Goede wrote:
> On 16-09-16 10:59, Michel Dänzer wrote:
>> On 16/09/16 05:37 PM, Hans de Goede wrote:
>>> On 16-09-16 08:26, Michel Dänzer wrote:
>>>> On 16/09/16 01:37 PM, Keith Packard wrote:
>>>>> @@ -1943,3 +19
On 16/09/16 05:37 PM, Hans de Goede wrote:
> On 16-09-16 08:26, Michel Dänzer wrote:
>> On 16/09/16 01:37 PM, Keith Packard wrote:
>>> This lets the video driver flush rendering to the kernel before the
>>> client receives a damage event to a pixmap which the client has
From: Michel Dänzer <michel.daen...@amd.com>
If --prefix isn't specified on the command line, $prefix contains "NONE"
at this point, not the default prefix value. So make install would
attempt to install the xorg.conf.d snippet to
${DESTDIR}NONE/share/X11/xorg.conf.d/.
Avoid
On 16/09/16 04:18 PM, Hans de Goede wrote:
> On 16-09-16 04:00, Michel Dänzer wrote:
>> On 16/09/16 06:50 AM, Eric Anholt wrote:
>>> Hans de Goede <hdego...@redhat.com> writes:
>>>
>>>> When using reverse prime we do 2 copies, 1 from the primary GPU's
&
ble);
> +}
FWIW, this will do nothing for GPU screens. I'm not sure whether or not
GPU screens need to be flushed for damage events, what are others'
thoughts on that?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 16/09/16 01:51 PM, Keith Packard wrote:
> Michel Dänzer <mic...@daenzer.net> writes:
>
>> Yes, glamor_flush is sufficient if the kernel drivers handle fences
>> correctly.
>
> I sent out a patch to flush rendering to a specific drawable for use by
&g
ted on copying from the screen pixmap to the shared pixmap,
especially if the scanout driver only updates once per CRTC scanout
refresh cycle. Feel free to take a look at xf86-video-amdgpu for how
this can be done.
--
Earthling Michel Dänzer | http://www.amd.com
Libre softw
be sufficient?
Yes, glamor_flush is sufficient if the kernel drivers handle fences
correctly.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signat
{
> @@ -450,9 +463,8 @@ xf86platformProbeDev(DriverPtr drvp)
> if (j == xf86_num_platform_devices)
> continue;
>
> -foundScreen = probeSingleDevice(_platform_devices[j], drvp,
> devList[i], 0);
> - if (!foundScreen)
> -co
On 13/09/16 09:51 AM, Michel Dänzer wrote:
> On 12/09/16 08:24 PM, Hans de Goede wrote:
>> When a slave-output is rotated the transformation is done on the blit
>> from master to slave GPU, so crtc->transform_in_use is not set, but we
>> still need to adjust the mouse pos
>rotation & 0xf) {
> case RR_Rotate_0:
> case RR_Rotate_180:
> default:
>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | M
On 12/09/16 05:24 PM, Hans de Goede wrote:
> On 12-09-16 09:47, Michel Dänzer wrote:
>> On 09/09/16 09:50 PM, Hans De Goede wrote:
>>> When a slave-output is rotated the transformation is done on the blit
>>> from master to slave GPU, so crtc->transform_in_use is
mething they're not intended
for. But between two evils, I'd choose the simpler one. :)
The cleaner alternative would be not using xf86_crtc_rotate_coord(_back)
but open-coding the correct logic, basically like in v7 but with the
reflection handling moved after the rotation handling. You can have
Reviewed
them again? I.e. is there
anything which needs to be able to distinguish between the ABI versions
before and after this change?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
On 01/09/16 12:27 AM, Alex Deucher wrote:
> On Wed, Aug 31, 2016 at 4:56 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
>
> Reviewed-by: Ale
gt; +if (crtc->transform_in_use || screen->isGPU)
> xf86_crtc_transform_cursor_position(crtc, _x, _y);
Use something like
if (crtc->transform_in_use || crtc->rotation != RR_Rotate_0)
instead. No need to call xf86_crtc_transform_cursor_position for a GPU
screen with crtc->r
On 08/09/16 04:18 PM, Hans de Goede wrote:
> On 08-09-16 07:59, Michel Dänzer wrote:
>> On 08/09/16 02:32 PM, Hans de Goede wrote:
>>> On 08-09-16 03:10, Michel Dänzer wrote:
>>>> On 08/09/16 12:43 AM, Hans de Goede wrote:
>>>>>
>>>>
On 08/09/16 02:32 PM, Hans de Goede wrote:
> On 08-09-16 03:10, Michel Dänzer wrote:
>> On 08/09/16 12:43 AM, Hans de Goede wrote:
>>>
>>> xf86_crtc_rotate_coord_back() is described as "Given a cursor source
>>> coordinate, rotate to a screen coor
On 08/09/16 10:23 AM, Alex Goins wrote:
> On Thu, 8 Sep 2016, Michel Dänzer wrote:
>
>> On 08/09/16 08:32 AM, Alex Goins wrote:
>>>
>>> I'm encountering some very strange issues when running these with PRIME
>>> Synchronization enabled, even after fixing
ing, they must be fixed). The problem is
> that glamor_egl_init() is making a GL context current without updating
> lastGLcontext, so glamor_make_current() short-circuits. Calling
> glamor_make_current() from glamor_egl_init() was my proposal
It certainly could be, but that would probably be an issue in your
kernel driver.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org
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
-
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 |
301 - 400 of 1234 matches
Mail list logo
