Hey,
not sure this is a bug, but since I have installed a new AMD Radeon RX 6700 XT
(Navy Flounder/Navi22) the amdgpu module triggers two "resource sanity checks"
on each boot (by the way: not sure what is supposed to cause the "G" taint to
the kernel – according to `lsmod | awk '{print $1}' |
Hey Harry,
Harry Wentland wrote on 08.08.2017 22:25:
> upstream kernels currently have only headless support. We're still
> working on getting our display driver accepted upstream but in the
> meantime you can compile it yourself from
>
Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> I've just a few points, since I'm not too enthused by the prospect of having
>> to
>> deal with yet another build system with yet another slightly different
>>
Hey Dylan,
I've just a few points, since I'm not too enthused by the prospect of having to
deal with yet another build system with yet another slightly different syntax.
But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
involved with Mesa and their opinion is what
Hey everybody,
Sandeep wrote on 06.11.2016 19:56:
> I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
> upstream kernel (or is this upto individual distros?)
>
> Is there any work left to be done/bugs to be fixed before it can be enabled
> by default?
just some feedback on
Emil Velikov wrote on 14.08.2015 10:17:
> On 14 August 2015 at 08:59, Kai Wasserbäch
> wrote:
>> Zhou, Jammy wrote on 14.08.2015 07:59:
>>> We tried several different ways already for the enumeration interface
>>> (libpciaccess, libudev, etc). But we ran into some problems with these
>>>
Zhou, Jammy wrote on 14.08.2015 07:59:
> We tried several different ways already for the enumeration interface
> (libpciaccess, libudev, etc). But we ran into some problems with these
> options for example when run Steam games which ships 32bit libraries
> (including libudev) in the steam
Dear Alex,
Alex Deucher wrote on 17.11.2014 17:58:
> On Sat, Nov 15, 2014 at 6:59 PM, Kai Wasserbäch dev.carbon-project.org> wrote:
>> Kai Wasserbäch wrote on 15.11.2014 22:22:
[...]
>>> I noticed, however, that the following line is showing up with be762d181e
>>> in dmesg:
>>>
Christian König wrote on 19.11.2014 20:40:
> Am 19.11.2014 um 19:28 schrieb Alex Deucher:
>> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
>> wrote:
>>> From: Christian König
>>>
>>> Use ring structure instead of index and provide vm_id and pd_addr
>>> separately.
>>>
>>> Signed-off-by:
Yes, that seems to fix the problem!
You can have my
Tested-by: Kai Wasserbäch
Thanks,
Kai
Christian König wrote on 19.11.2014 17:18:
> Ah! Yes of course, we have changed we way memory is allocated for the BO list
> in
> the meantime.
>
> Does it work if you replace the last patch in the
Dear Christian,
Christian König wrote on 19.11.2014 14:35:
> Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch:
>> Dear Christian,
>> Christian König wrote on 19.11.2014 14:01:
>>> From: Christian König
>>>
>>> This way the necessary VM update is kicked off immediately
>>> if all BOs involved are
Dear Christian,
Christian König wrote on 19.11.2014 14:01:
> From: Christian König
>
> This way the necessary VM update is kicked off immediately
> if all BOs involved are in GPU accessible memory.
>
> v2: fix vm lock
> v3: immediately update unmaps as well
>
> Signed-off-by: Christian
Andy Furniss wrote on 15.11.2014 23:29:
> Kai Wasserbäch wrote:
>> Kai Wasserbäch wrote on 15.11.2014 16:33:
>>> Is there anything besides a bisect you would need to debug this?
>>
>> Ok, I did a bisection, but that time was wasted for sure. My "first bad
>> commit"
>> isn't bad at all. Is
Kai Wasserbäch wrote on 15.11.2014 22:22:
> Kai Wasserbäch wrote on 15.11.2014 16:33:
>> Is there anything besides a bisect you would need to debug this?
>
> Ok, I did a bisection, but that time was wasted for sure. My "first bad
> commit"
> isn't bad at all. Is there any way to improve that
Kai Wasserbäch wrote on 15.11.2014 16:33:
> Is there anything besides a bisect you would need to debug this?
Ok, I did a bisection, but that time was wasted for sure. My "first bad commit"
isn't bad at all. Is there any way to improve that experience? I'm really loathe
to go through the dozen
Kai Wasserbäch wrote on 15.11.2014 16:33:
> I've built your drm-next-3.19-wip branch (commit
> be762d181e130d0e6e630f823400e9e1ba3bafd8) and with that kernel and the
> graphics
> stack detailed below, [...]
Sorry, forgot to include the stack, here we go:
My current stack is (Debian testing as
Dear Alex,
I've built your drm-next-3.19-wip branch (commit
be762d181e130d0e6e630f823400e9e1ba3bafd8) and with that kernel and the graphics
stack detailed below, I can't run any of my Steam games anymore. All of them
immediately go into the defunct state, when their 3D engine is powered up (ie. I
17 matches
Mail list logo
