initialize
req.reply.tval_usec = req32.reply.tval_usec;
before calling drm_ioctl_kernel, since it's not aliased by any req.request.*
member, and drm_wait_vblank_ioctl doesn't always write to it.
--
Earthling Michel Dänzer | https://redhat.com
Libr
issue and mesa was using
SYS_kcmp to compare device node fds.
A far shorter and more portable solution is possible, so let me
prepare a Mesa patch.
Make sure to read my comments on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :)
--
Earthling Michel Dänzer
On 2021-02-08 2:34 p.m., Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the
On 2021-02-08 12:49 p.m., Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend
select if CONFIG_DRM is
unfortunately needed I think.
Per above, not sure this is really true.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
Without __GFP_NOWARN, attempts at allocating huge pages can trigger
dmesg splats like below (which are essentially noise, since TTM falls
back to normal pages if it can't get a huge one).
[ 9556.710241] clinfo: page allocation failure: order:9,
mode:0x194dc2(GFP_HIG
ssure.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
least (if
DMA_BUF_IOCTL_IMPORT_SYNC_FILE is still controversial).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2020-09-21 4:40 p.m., Sasha Levin wrote:
From: Michel Dänzer
[ Upstream commit 2f228aab21bbc74e90e267a721215ec8be51daf7 ]
Don't check drm_crtc_state::active for this either, per its
documentation in include/drm/drm_crtc.h:
* Hence drivers must not consult @active in their va
doesn't support
suspend-to-RAM on Apple PowerPC notebooks.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
ell, because you
didn't trim the quoted text (hint, hint).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
50).
>
> In this case the patch is a clear NAK since you haven't root caused the
> issue and are just working around it in a very questionable manner.
To be fair though, amdgpu & radeon are already disabling write-combining
for system memory pages in 32-bit x86 kernels for similar reasons.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
3
> -#define KMS_DRIVER_MINOR 36
> +#define KMS_DRIVER_MINOR 37
> #define KMS_DRIVER_PATCHLEVEL0
>
> int amdgpu_vram_limit = 0;
>
This requires the parent commit fdf83646c0542ecfb9adc4db8f741a1f43dca058
"drm/amdgpu: invalidate L2 before SDMA IBs (v2)
again sorry for the brouhaha, I just honestly didn't
realize before how tricky this case was for the scripts.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2019-09-03 10:16 p.m., Daniel Vetter wrote:
> On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote:
>> On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
>>> On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
>>>> On 2019-09-03 6:23 p.m., Sasha Le
nches which didn't have other corresponding changes, so they ended
up breaking stuff instead of fixing anything.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
ks for that.
> since it's our native granularity after all (while a timestamp is not).
Note that variable refresh rate (Adaptive Sync / FreeSync / G-Sync)
changes things in this regard. It makes the vblank length variable, and
if you wait for multiple vblanks between flips, you get t
On 2019-03-25 10:05 p.m., Kangjie Lu wrote:
> In case alloc_workqueue fails, the fix frees memory and
> returns -ENOMEM to avoid potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> v2: use radeon_crtc_destroy to properly clean up resources as
> sugge
about non-cache coherent likely not working *at
>>> all* unless the optimization is enabled.
>>
>> As Michel tried to explain this CAN'T happen. The optimization is a
>> purely optional request from userspace.
>>
>
> Right.
>
> S
>> -
>> - if (bo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
>> - DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT
>> for "
>> - "better performance thanks to
>> write-combini
On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
>> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>>>> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
>
On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>>
>> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>>>>
>>>> On 2019-01-21 5:30 p.m., Ard B
On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>>
>> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>>>
>>>> Until that happens we sh
27;optimization' to get things working.
FWIW, the amdgpu driver doesn't rely on non-snooped transfers for
correct basic operation (the scenario Christian brought up is a very
specialized use-case), so that shouldn't be an issue.
--
Earthling Michel Dänzer
for
this, because other TTM / driver code will still consider the memory
uncacheable. E.g. the amdgpu driver will program the GPU to treat the
memory as uncacheable, so it won't participate in cache coherency
protocol for it, which is unlikely to work as expected in general
27;t needed in older kernels.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
>
> Cc: sta...@vger.kernel.org # v4.2+
> Signed-off-by: Yu Zhao
Both patches applied to amd-staging-drm-next (should land in 5.0), thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2019-01-07 5:00 a.m., Yu Zhao wrote:
> On Thu, Jan 03, 2019 at 05:33:19PM +0100, Michel Dänzer wrote:
>> On 2018-12-30 2:00 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses d
return ERR_PTR(-EINVAL);
> + }
>
> obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
> if (obj == NULL) {
>
Apart from the above, the v5 series looks good to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-12-23 10:44 p.m., Yu Zhao wrote:
> On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
>> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and
On 2018-12-21 2:26 p.m., Daniel Vetter wrote:
> On Fri, Dec 21, 2018 at 10:47:27AM +0100, Michel Dänzer wrote:
>> On 2018-12-20 6:16 p.m., Michel Dänzer wrote:
>>> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
>>>> On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher wrote:
second, but I suspect even a
single one could cause a frame drop. I assume the issue is that gamma
updates are done as separate atomic commits, which can delay other
commits for page flips.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-12-20 6:16 p.m., Michel Dänzer wrote:
> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
>> On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher wrote:
>>> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter wrote:
>>
>>>> Not sure about the gamma thing since we
eight, 8);
> + if (obj->size < pitch * height) {
> + dev_err(&dev->pdev->dev, "Invalid GEM size: expecting %d but
> got %d\n",
> + pitch * height, obj->size);
Same comment as patch 2, and maybe
pu_align_pitch(adev, mode_cmd->width, cpp, false);
Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width,
otherwise it'll spuriously fail for larger but well-aligned pitches.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
houldn't be printed by default, or buggy / malicious
userspace can spam dmesg. I suggest using DRM_DEBUG_KMS or DRM_DEBUG_DRIVER.
> + return ERR_PTR(-EINVAL);
> + }
>
> obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
> if (obj ==
pflip_status thus will refuse to notify the job
> completion. The job will eventually times out.
>
> Reverse the order of calling page_flip and setting pflip_status to
> fix the race.
There is no race, amdgpu_crtc->pflip_status is protected by dev->event_
and create a new commit otherwise?
Otherwise the atomic API just moves this same problem to be solved by
userspace.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
No need for pr_err here, the pr_err message in ttm_bo_evict is enough
to draw attention to something not going as planned.
Signed-off-by: Michel Dänzer
---
Similar to a previous patch, but this one leaves the pr_err messages in
ttm_bo_evict untouched.
drivers/gpu/drm/ttm
On 2018-12-06 5:46 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 17:39 +0800, Zhang, Jerry(Junwei) wrote:
>> On 12/6/18 5:33 PM, Koenig, Christian wrote:
>>> Am 06.12.18 um 10:09 schrieb Michel Dänzer:
>>>> On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote:
>
On 2018-12-06 5:10 p.m., Daniel Thompson wrote:
> On Thu, Dec 06, 2018 at 03:41:16PM +0100, Michel Dänzer wrote:
>> On 2018-12-06 1:23 p.m., Joe Perches wrote:
>>> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
>>>> In contrast to the 2b case, the pr_debug o
On 2018-12-06 1:23 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
>> In contrast to the 2b case, the pr_debug output isn't visible by default
>> with 1b, so the latter doesn't fit "always produce output" either.
>
> I th
o believe that ADDFB should be made to always prefer host byte
> order -- this is how all of the existing implementations work in
> practice. However e.g. nouveau wants DRM_FORMAT_XRGB. But it still
> treats it as host byte order. This will become more important in a
> world
:) after these
changes as they did before. So no concerns from my side anymore.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-05-25 10:41 AM, Christoph Hellwig wrote:
> On Tue, May 22, 2018 at 03:13:58PM +0200, Christian König wrote:
>> Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
>>> On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
>>>> On Wed, May 02, 2018 at 04:31:09PM +0200,
On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
> On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
>>> No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface
>>> for dma allocations and just cause problems. I actually plan to
>>> ge
c_attrs sooner, and only
> allow either GFP_KERNEL or GFP_DMA passed in dma_alloc_coherent.
How about GFP_TRANSHUGE_LIGHT? TTM uses that to opportunistically
allocate huge pages (GFP_TRANSHUGE can result in unacceptably long
delays with memory pressure).
--
Earthling Michel Dänzer
On 2018-04-29 01:56 AM, Ilia Mirkin wrote:
> On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer wrote:
>>
>> Unfortunately, there was an swiotlb regression (not directly related to
>> Christian's work) shortly after this fix, also in 4.16-rc1, which is now
>> fixed in
ssions introduced by commit
0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation" in 4.16-rc1.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
The result was printing the warning only when we were explicitly asked
not to.
Cc: sta...@vger.kernel.org
Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation"
Signed-off-by: Michel Dänzer
---
lib/swiotlb.c | 2 +-
1 fi
On 2018-04-29 09:02 AM, Christian König wrote:
> Am 29.04.2018 um 01:02 schrieb Michel Dänzer:
>> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer
>>> wrote:
>>>> From: Michel Dänzer
>&
On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
>> try to allocate huge pages. However, not all drivers can take adva
From: Michel Dänzer
Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
try to allocate huge pages. However, not all drivers can take advantage
of huge pages, but they would incur the overhead for allocating and
freeing them anyway.
Now, drivers which can take advantage of
[ Dropping Roger He, his e-mail address seems to bounce ]
On 2018-04-27 04:51 AM, zhoucm1 wrote:
> On 2018年04月26日 23:06, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> When it's set, TTM tries to allocate huge pages if possible.
> Do you mean original driver doe
From: Michel Dänzer
GFP_TRANSHUGE tries very hard to allocate huge pages, which can result
in long delays with high memory pressure. I have observed firefox
freezing for up to around a minute due to this while restic was taking
a full system backup.
Since we don't really need huge pages
From: Michel Dänzer
When it's set, TTM tries to allocate huge pages if possible. Drivers
which can take advantage of huge pages should set it.
Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.
Cc: sta...@vger.kernel.org
Signed-o
int radeon_agpmode = 0;
> +#endif
> int radeon_vram_limit = 0;
> int radeon_gart_size = -1; /* auto */
> int radeon_benchmarking = 0;
>
Pushed to amd-staging-drm-next, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
->fini_status = -ERESTARTSYS;
> else
> entity->fini_status = wait_event_killable(sched->job_scheduled,
>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-04-20 09:40 PM, Felix Kuehling wrote:
> On 2018-04-20 10:47 AM, Michel Dänzer wrote:
>> On 2018-04-11 11:37 AM, Christian König wrote:
>>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>>> 2018-04-09 11:42 GMT+02:00 Christian König
>>>> :
>>&g
alloc_pages_nodemask to be more
precise), called from ttm_alloc_new_pages.
At least in the case of Firefox, this happens due to Mesa internal BO
allocations for glTex(Sub)Image, so it's not obvious that Firefox is
doing something wrong.
I never noticed this before this week. Before, I was running 4.15.y +
DRM subsystem changes from 4.16. Maybe something has changed in core
code, trying harder to allocate huge pages.
Maybe TTM should only try to use any huge pages that happen to be
available, not spend any (/ "too much"?) additional effort trying to
free up huge pages?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-04-04 11:36 AM, Lucas Stach wrote:
> Am Mittwoch, den 04.04.2018, 11:09 +0200 schrieb Michel Dänzer:
>> On 2018-03-26 04:36 PM, Lucas Stach wrote:
>>> Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko:
>>>> On Tue 30-01-18 10:29:10, Michel Dänzer
On 2018-03-26 04:36 PM, Lucas Stach wrote:
> Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko:
>> On Tue 30-01-18 10:29:10, Michel Dänzer wrote:
>>> On 2018-01-24 12:50 PM, Michal Hocko wrote:
>>>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>&g
CONFIG_X86_PAT for better performance
> \
>thanks to write-combining
> +#endif
>
> if (bo->flags & RADEON_GEM_GTT_WC)
> DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for
> "
>
Merged on the internal amd-staging-drm-next branch, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-01-30 12:56 PM, Christian König wrote:
> Am 30.01.2018 um 12:42 schrieb Michel Dänzer:
>> On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
>>> On 30.01.2018 12:34, Michel Dänzer wrote:
>>>> On 2018-01-30 12:28 PM, Christian König wrote:
>>>>>
On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
> On 30.01.2018 12:34, Michel Dänzer wrote:
>> On 2018-01-30 12:28 PM, Christian König wrote:
>>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>>>> On 2018-01-30 11:40 AM, Christian König wrote:
>>>>>
On 2018-01-30 12:28 PM, Christian König wrote:
> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>> On 2018-01-30 11:40 AM, Christian König wrote:
>>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>>>> [SNIP]
>>>>> Would it be ok to hang onto potentially
On 2018-01-30 11:40 AM, Christian König wrote:
> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>> [SNIP]
>>> Would it be ok to hang onto potentially arbitrary mmget references
>>> essentially forever? If that's ok I think we can do your process based
>>> ac
On 2018-01-30 11:42 AM, Daniel Vetter wrote:
> On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
>> On 2018-01-30 10:31 AM, Daniel Vetter wrote:
>>
>>> I guess a good first order approximation would be if we simply charge any
>>> newly allocated bu
On 2018-01-30 10:31 AM, Daniel Vetter wrote:
> On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote:
>> Am 24.01.2018 um 12:50 schrieb Michal Hocko:
>>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>>>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
>>>> 2. If the OOM killer kills a process which is sharing BO
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
>>>> 2. If the OOM killer kills a process which is sharing BO
On 2018-01-24 12:01 PM, Michal Hocko wrote:
> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
>> On 2018-01-24 10:28 AM, Michal Hocko wrote:
> [...]
>>> So how exactly then helps to kill one of those processes? The memory
>>> stays pinned behind or do I still misunders
On 2018-01-24 10:28 AM, Michal Hocko wrote:
> On Tue 23-01-18 17:39:19, Michel Dänzer wrote:
>> On 2018-01-23 04:36 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 15:27:00, Roman Gushchin wrote:
>>>> On Thu, Jan 18, 2018 at 06:00:06PM +0100, Michal Hocko wrote:
>>
entical with the end consumer.
That's actually not really true. Even in cases where a BO is shared with
a different process, it is still used at least occasionally in the
process which allocated it as well. Otherwise there would be no point in
sharing it between processes.
There should be no problem if the memory of a shared BO is accounted for
in each process sharing it. It might be nice to scale each process'
"debt" by 1 / (number of processes sharing it) if possible, but in the
worst case accounting it fully in each process should be fine.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
t; descriptor is used by more than one at the same time.
In that case, accounting a BO as suggested by Michal above, in every
process that shares it, should work fine, shouldn't it?
The OOM killer will first select the process which has more memory
accounted for other things than the BOs shared with another process.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-01-19 11:02 AM, Michel Dänzer wrote:
> On 2018-01-19 10:58 AM, Christian König wrote:
>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>>> On 2018-01-19 09:39 AM, Christian König wrote:
>>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>>>>>
On 2018-01-19 10:58 AM, Christian König wrote:
> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>> On 2018-01-19 09:39 AM, Christian König wrote:
>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>>>> On Thu 18-01-18 12:01:32, Eric Anholt wrote:
>>>>> Mi
and consider those in oom_badness? The rule would be
>> that such a memory is bound to the process life time. I guess we will
>> find more users for this later.
>
> I already tried that and the problem with that approach is that some
> buffers are not created by the application which actually uses them.
>
> For example X/Wayland is creating and handing out render buffers to
> application which want to use OpenGL.
>
> So the result is when you always account the application who created the
> buffer the OOM killer will certainly reap X/Wayland first. And that is
> exactly what we want to avoid here.
FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland
anymore. With DRI3 and Wayland, buffers are allocated by the clients and
then shared with the X / Wayland server.
Also, in all cases, the amount of memory allocated for buffers shared
between DRI/Wayland clients and the server should be relatively small
compared to the amount of memory allocated for buffers used only locally
in the client, particularly for clients which create significant memory
pressure.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
couldn't figure out how to configure the kernel to get any of this code
> to compile.
Just enabling CONFIG_DRM_AMDGPU should be enough AFAICT.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2017-12-19 11:37 AM, Michel Dänzer wrote:
> On 2017-12-18 08:01 PM, Tobias Klausmann wrote:
>> On 12/18/17 7:06 PM, Mike Galbraith wrote:
>>> Greetings,
>>>
>>> Kernel bound workloads seem to trigger the below for whatever reason.
>>> I only see t
an König
Date: Thu Jul 6 09:59:43 2017 +0200
drm/ttm: add transparent huge page support for DMA allocations v2
Try to allocate huge pages when it makes sense.
v2: fix comment and use ifdef
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2017-12-01 08:39 PM, Darren Hart wrote:
> On Tue, Nov 28, 2017 at 08:41:47PM +0100, Michel Dänzer wrote:
>> On 2017-11-28 08:30 PM, Andy Shevchenko wrote:
>>> On Tue, Nov 28, 2017 at 8:06 PM, Michel Dänzer wrote:
>>>> On 2017-11-28 05:57 PM, Darren Hart wrote:
&g
On 2017-11-28 08:30 PM, Andy Shevchenko wrote:
> On Tue, Nov 28, 2017 at 8:06 PM, Michel Dänzer wrote:
>> On 2017-11-28 05:57 PM, Darren Hart wrote:
>>> On Tue, Nov 28, 2017 at 04:17:58PM +0100, Michel Dänzer wrote:
>>>> We were always checking bit 0 (whi
On 2017-11-28 05:57 PM, Darren Hart wrote:
> On Tue, Nov 28, 2017 at 04:17:58PM +0100, Michel Dänzer wrote:
>> We were always checking bit 0 (which represents the docked state)
>> regardless of the mask.
>>
>> Fixes the "tablet mode" state always being rep
.
Cc: sta...@vger.kernel.org
Fixes: ("platform/x86: hp-wmi: Refactor dock and tablet state fetchers")
Signed-off-by: Michel Dänzer
---
drivers/platform/x86/hp-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platfor
abase used for other OSes,
which minimizes the potential for error. We used hand-written headers in
the radeon driver, and there was a fair number of bugs due to subtle
errors in them.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
tead of u64 in new sequence event
>
> Suggested-by: Daniel Vetter
> Suggested-by: Ville Syrjälä
>
> v3:
>
> * Removed FIRST_PIXEL_OUT_FLAG
> * Document that the timestamp in the query and event are
>that of the first pixel leaving the display engine for
>the d
On 06/08/17 12:42 PM, Keith Packard wrote:
> Michel Dänzer writes:
>
>> [...]
>>
>>> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use
>>> next sequence if we've missed */
>>
>> Do you have userspace making use
the flag (not) set,
some userspace will almost certainly break. So effectively we can never
make the flag have any effect.
The way to go here is to drop the flag for now and document the
behaviour explicitly. If unexpectedly a real need for different
behaviour comes up in the future, we can add a flag for
rspace making use of DRM_CRTC_SEQUENCE_NEXT_ON_MISS? If
not, drop it.
> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT0x0004 /* Signal when
> first pixel is displayed */
I thought there was consensus that this flag is pointless.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
>> within the kernel. We need to write that target back to the
>> ioctl buffer and update the flags bits so that if the wait is
>> interrupted by a signal, when it is re-started, it will target
>> precisely the same vblank count as before.
>>
>
On 07/07/17 10:34 AM, Michel Dänzer wrote:
> On 07/07/17 12:04 AM, Keith Packard wrote:
>> Michel Dänzer writes:
>>
>>>> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev)
>>>>if (!dev_priv)
>>>>
On 07/07/17 12:04 AM, Keith Packard wrote:
> Michel Dänzer writes:
>
>>> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev)
>>> if (!dev_priv)
>>> return -EINVAL;
>>>
>>> + if (dev->driver->
On 06/07/17 04:45 PM, Michel Dänzer wrote:
> On 06/07/17 07:10 AM, Keith Packard wrote:
>> This modifies the datatypes used by the vblank code to provide both 64
>> bits of vblank count and to increase the resolution of the vblank
>> timestamp from microseconds to nanoseco
install(struct drm_device *dev)
> if (!dev_priv)
> return -EINVAL;
>
> + if (dev->driver->get_vblank_counter)
> + dev->max_vblank_count = 0x;
What's the purpose of this? All drivers providing get_vblank_counter
should already initializ
On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>>>> This makes the redundant fb helpers .load_
ther bug,
> but might be relevant for your use-case. Just try to run both an fbdev
> application and some kms-native thing, and then SIGKILL the native kms
> app.
>
> But since pre-existing not really required, and probably too much effort.
I suspect somet
irq_event_percpu+0x20/0x90
> [ 249.952892] handle_irq_event+0x46/0xb0
> [ 249.952897] handle_edge_irq+0x13d/0x370
> [ 249.952903] handle_irq+0x66/0x210
> [ 249.952908] ? __local_bh_enable+0x34/0x50
> [ 249.952914] do_IRQ+0x7e/0x1b0
> [ 249.952920] common_interrupt+0x95/0x95
Weird
On 10/05/17 08:30 PM, Christian König wrote:
> Am 10.05.2017 um 02:23 schrieb Michel Dänzer:
>> On 03/05/17 09:46 PM, Christian König wrote:
>>> Am 02.05.2017 um 22:04 schrieb SF Markus Elfring:
>>>> From: Markus Elfring
>>>> Date: Tue, 2 May 2017 22:00:0
vel/2017-May/140837.html
and followups, I'm afraid we'll have to make sure Markus' patches have
been tested adequately before applying them.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
1 - 100 of 204 matches
Mail list logo
