Am 04.09.2018 um 06:04 schrieb zhoucm1:
On 2018年09月03日 19:19, Christian König wrote:
Am 03.09.2018 um 12:07 schrieb Chunming Zhou:
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_
Am 04.09.2018 um 03:00 schrieb Bas Nieuwenhuizen:
This is an initial proposal for format modifiers for AMD hardware.
It uses 48 bits including a chip generation, leaving 8 bits for
a format version number.
I'm absolutely not an expert on this, but as far as I know the major
problem with this
On 2018年09月04日 15:00, Christian König wrote:
Am 04.09.2018 um 06:04 schrieb zhoucm1:
On 2018年09月03日 19:19, Christian König wrote:
Am 03.09.2018 um 12:07 schrieb Chunming Zhou:
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Chris
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1. Each signaling point is a fence implementation with an rb node.
2. Each node keeps a reference to the last previously inserted node.
3. Each node is referenced by the sync object itself.
4. Before each signal/wait operation
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1. Each signaling point is a fence implementation with an rb node.
2. Each node keeps a reference to the last previously inserted node.
3. Each node is referenced by the sync obje
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1. Each signaling point is a fence implementation with an rb node.
2. Each node keeps a reference to the last previously inserted node.
3.
On 2018年09月04日 16:42, Christian König wrote:
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1. Each signaling point is a fence implementation with an rb node.
2. Each node keeps a re
On Tuesday, 2018-09-04 16:24:44 +1000, Dave Airlie wrote:
> On Mon, 3 Sep 2018 at 18:47, Daniel Vetter wrote:
> >
> > I picked up a bunch of the pieces from wayland's version:
> >
> > https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
> >
> > The weston one is fairly simila
Am 04.09.2018 um 11:00 schrieb zhoucm1:
On 2018年09月04日 16:42, Christian König wrote:
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1. Each signaling point is a fence implementation
On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
wrote:
> This is an initial proposal for format modifiers for AMD hardware.
>
> It uses 48 bits including a chip generation, leaving 8 bits for
> a format version number.
>
> On gfx6-gfx8 we have all the fields influencing sample locations
> in mem
Hi,
On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
> On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
> wrote:
> > +/* The chip this is compatible with.
> > + *
> > + * If compression is disabled, use
> > + * - AMDGPU_CHIP_TAHITI for GFX6-GFX8
> > + * - AMDGPU_CHIP_VEGA10 for GFX9+
> >
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Hi,
On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
wrote:
+/* The chip this is compatible with.
+ *
+ * If compression is disabled, use
+ * - AMDGPU_CHIP_TAHITI for GFX6-GFX8
+ * - AMDGPU_C
On Tue, Sep 4, 2018 at 12:04 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
> wrote:
> > This is an initial proposal for format modifiers for AMD hardware.
> >
> > It uses 48 bits including a chip generation, leaving 8 bits for
> > a format version number.
> >
> > O
Hi,
On Tue, 4 Sep 2018 at 11:44, Christian König
wrote:
> Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > Right. The conclusion, after people went through and started sorting
> > out the kinds of formats for which they would _actually_ export real
> > colour buffers for, that most vendors defini
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > Hi,
> >
> > On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
> > > On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
> > > wrote:
> > > > +/* The chip this is compatible with.
>
On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
>
> On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> > Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > > Hi,
> > >
> > > On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
> > > > On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuiz
+everyone again
On Tue, Sep 4, 2018 at 2:39 PM Bas Nieuwenhuizen
wrote:
>
> On Tue, Sep 4, 2018 at 2:22 PM Daniel Stone wrote:
> >
> > Hi,
> >
> > On Tue, 4 Sep 2018 at 11:44, Christian König
> > wrote:
> > > Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > > > Right. The conclusion, after peopl
On Tue, Sep 04, 2018 at 10:02:40AM +0100, Eric Engestrom wrote:
> On Tuesday, 2018-09-04 16:24:44 +1000, Dave Airlie wrote:
> > On Mon, 3 Sep 2018 at 18:47, Daniel Vetter wrote:
> > >
> > > I picked up a bunch of the pieces from wayland's version:
> > >
> > > https://gitlab.freedesktop.org/wayland
Am 04.09.2018 um 14:22 schrieb Daniel Stone:
Hi,
On Tue, 4 Sep 2018 at 11:44, Christian König
wrote:
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Right. The conclusion, after people went through and started sorting
out the kinds of formats for which they would _actually_ export real
colour bu
Am 04.09.2018 um 14:26 schrieb Daniel Vetter:
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Hi,
On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
wrote:
+/* The chip this is c
On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
> On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
> >
> > On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> > > Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > > > Hi,
> > > >
> > > > On Tue, 4 Sep 2018 at 11:
Am 04.09.2018 um 15:03 schrieb Daniel Vetter:
On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Hi,
On Tue, 4 Se
On Tue, Sep 4, 2018 at 3:12 PM, Christian König
wrote:
> Am 04.09.2018 um 15:03 schrieb Daniel Vetter:
>>
>> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
>>>
>>> On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian
Am 04.09.2018 um 15:17 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 3:12 PM, Christian König
wrote:
Am 04.09.2018 um 15:03 schrieb Daniel Vetter:
On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 1
On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
>
> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
> > On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
> > >
> > > On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> > > > Am 04.09.2018 um 12:15 schrieb Da
The first one should already be fixed.
Not sure where the second comes from. Can you narrow that down further?
Christian.
Am 04.09.2018 um 15:46 schrieb Tom St Denis:
First is caused by this commit while running a GL heavy application.
d78c1fa0c9f815fe951fd57001acca3d35262a17 is the first bad
Hello Alex Deucher,
The patch 5f152a572c10: "drm/radeon: use pcie functions for link
width" from Jun 25, 2018, leads to the following static checker
warning:
drivers/gpu/drm/radeon/cik.c:9646 cik_pcie_gen3_enable()
warn: dead code because of 'speed_cap == 21' and 'speed_cap != 21'
On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
>> > On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
>> > >
>> > > On Tue, Sep 04, 2018 at 12:44:19PM +0200,
Hi Michał,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc2 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
> wrote:
> > On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
> >>
> >> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
> >> > On Tue, Sep 4, 2018 at 2:26 PM Daniel Vet
On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
>> wrote:
>> > On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
>> >>
>> >> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nie
Sure:
d2917f399e0b250f47d07da551a335843a24f835 is the first bad commit
commit d2917f399e0b250f47d07da551a335843a24f835
Author: Christian König
Date: Thu Aug 30 10:04:53 2018 +0200
drm/amdgpu: fix "use bulk moves for efficient VM LRU handling" v2
First step to fix the LRU corruption,
Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 0
On Tue, Sep 4, 2018 at 7:48 PM Christian König
wrote:
>
> Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
> > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
> > wrote:
> >> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
> >>> On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
> >>> wrote:
On Tue, Sep 4, 2018 at 7:57 PM Bas Nieuwenhuizen
wrote:
>
> On Tue, Sep 4, 2018 at 7:48 PM Christian König
> wrote:
> >
> > Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
> > > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
> > > wrote:
> > >> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrot
Am 04.09.2018 um 20:00 schrieb Bas Nieuwenhuizen:
On Tue, Sep 4, 2018 at 7:57 PM Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 7:48 PM Christian König
wrote:
Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 4:43
On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 7:48 PM Christian König
> wrote:
>>
>> Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
>> > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
>> > wrote:
>> >> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
>>
On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
> wrote:
> > On Tue, Sep 4, 2018 at 7:48 PM Christian König
> > wrote:
> >>
> >> Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
> >> > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
> >> >
On Tue, Sep 4, 2018 at 8:31 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
>> wrote:
>> > On Tue, Sep 4, 2018 at 7:48 PM Christian König
>> > wrote:
>> >>
>> >> Am 04.09.2018 um 18:37 schrieb Daniel Vett
On Tue, Sep 4, 2018 at 9:28 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 8:31 PM, Bas Nieuwenhuizen
> wrote:
> > On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
> >>
> >> On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
> >> wrote:
> >> > On Tue, Sep 4, 2018 at 7:48 PM Christian Köni
On Tue, Sep 04, 2018 at 09:36:01PM +0200, Bas Nieuwenhuizen wrote:
> On Tue, Sep 4, 2018 at 9:28 PM Daniel Vetter wrote:
> >
> > On Tue, Sep 4, 2018 at 8:31 PM, Bas Nieuwenhuizen
> > wrote:
> > > On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
> > >>
> > >> On Tue, Sep 4, 2018 at 7:57 PM, Ba
On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom wrote:
>
> On 09/03/2018 06:33 PM, Daniel Vetter wrote:
> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
> >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
> >>> On 08/31/2018 05:27 PM, Emil Velikov wrote:
> On 31 August 201
do_div expects the 1st argument in 64bit instead of 32bit.
Change-Id: Id2032a43727e7f1fa516d3565354d412a561
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerpla
On 2018年09月04日 17:20, Christian König wrote:
Am 04.09.2018 um 11:00 schrieb zhoucm1:
On 2018年09月04日 16:42, Christian König wrote:
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1
> -Original Message-
> From: amd-gfx On Behalf Of Evan
> Quan
> Sent: Tuesday, September 4, 2018 10:21 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan
> Subject: [PATCH] drm/amd/powerplay: fix compile warning for wrong data
> type
>
> do_div expects the 1st argument in 64bit inst
> -Original Message-
> From: Deucher, Alexander
> Sent: 2018年9月5日 12:33
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan
> Subject: RE: [PATCH] drm/amd/powerplay: fix compile warning for wrong
> data type
>
> > -Original Message-
> > From: amd-gfx On Behalf Of
do_div expects the 1st argument in 64bit instead of 32bit.
Drop the usage of do_div as it seems unnecessary.
V2: drop usage of do_div completely
Change-Id: Id2032a43727e7f1fa516d3565354d412a561
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 4 ++--
1 file
Am 05.09.2018 um 05:36 schrieb zhoucm1:
On 2018年09月04日 17:20, Christian König wrote:
Am 04.09.2018 um 11:00 schrieb zhoucm1:
On 2018年09月04日 16:42, Christian König wrote:
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb
48 matches
Mail list logo