It appears drm-next TTM cleanup broke something . . .

Wed Oct 21 08:30:25 UTC 2020

Hi

On 21.10.20 10:14, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 10:03 AM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>>
>> Hi
>>
>> On 19.10.20 21:43, Kevin Brace wrote:
>>> Hi Sam,
>>>
>>> Thanks for asking the question.
>>> The current OpenChrome DRM code has these two major issues.
>>>
>>> 1) It does not support atomic modesetting
>>>
>>> I do internally have working code to support atomic modesetting, but it is not ready for committing into the upstream OpenChrome DRM repository.
>>> In particular, it suffers from a freeze relating to a cursor plane.
>>> The freeze is a bad kind that kern.log does not really tell me what is wrong.
>>> If I disable hardware cursor, the atomic modesetting based OpenChrome DRM appears to work okay.
>>> In other words, I am getting close to getting atomic modesetting working, but I am stuck.
>>
>> This could be related to the memory problems. See below. Otherwise, I
>> suggest to reduce the driver to the minimum functionality that is
>> required for modesetting (even without HW cursors) and submit this code
>> for review and merging.
>>
>>>
>>>
>>> 2) Double allocation of visible portion of frame buffer
>>>
>>> This is a big problem left behind from the previous developer who developed OpenChrome prior to me.
>>> For some reason, the developer wanted to allocate visible portion of the frame buffer to be the maximum possible size supported by the detected monitor when initializing the frame buffer inside OpenChrome DRM code.
>>> I believe Radeon DRM does something similar to that.
>>> The problem is, OpenChrome DDX allocates an equal sized frame buffer visible portion during the DDX's initialization.
>>> This means that we got two same sized visible portions allocated, but OpenChrome DDX and OpenChrome DRM combined should really be allocating only one.
>>> At this point, OpenChrome is not supporting double buffering.
>>> This double allocation of a visible portion of the frame buffer contributes to a X Server crash when the screen is resized and 16 MB or less (i.e., 8 MB) shared frame buffer is reserved by the system via BIOS setup.
>>> I personally think letting OpenChrome DRM allocate the visible portion of the frame buffer is the way to go, but if so, how do I get the DDX or shadow FB to access the frame buffer visible portion allocated by OpenChrome DRM?
>>> Any suggestions on what to do about this issue will be greatly appreciated.
>>> Perhaps, I should post a question to dri-devel regarding this issue.
>>> I really do not know what I should do at this point.
>>
>> The double allocation is expected. Atomic modesetting requires two
>> framebuffers in video memory during the pageflip. You have to sort out
>> the modes where 2 framebuffers do not fit into video memory at the same
>> time.
> 
> What we have done on severly restricted discrete gpu is to keep one
> framebuffer for everyone in vram, and blt the kms framebuffers over as
> needed. With all the dirty tracking helpers for atomic that's like a
> one-liner to set up (or just slightly more). I think cirrus works like
> that (but it's using cpu memcpy since that's the only thing that
> exists, I guess openchrome could even use the blitter for this).

A yes, converting to SHMEM is also an option. But it prevents any kind
of 3d acceleration, if you want to add that as well.

> 
> The more usual approach is what nouveau guys already explained: Just
> run fbcon at very low resolution so it doesn't consume too much space.

A better approach is to kill openchromes custom fbdev implementation
entirely. During a review, we'd probably ask you to do this anyway. :)

Go for the generic fbdev emulation and set struct
drm_mode_config.prefer_shadow_fbdev to true. This will give you a shadow
buffer for the console, and the actual fbdev framebuffer can be evicted
from video memory when the space is required.

Best regards
Thomas

> -Daniel
> 
>> The mode_valid callback in struct drm_mode_config_funcs [1] is a good
>> place to do this. Check the mode's pixels with the maximum BPC against
>> the available memory. Example code is at [2]. You should also plane for
>> common additional layers, such as HW cursors, to require video memory.
>> So maybe test the mode against 80% of the video memory.
>>
>> Best regards
>> Thomas
>>
>> [1]
>> https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/openchrome/openchrome_fb.c?h=drm-next-5.10&id=22e0ee2460b4b70cde562b7a3818ae94c2786f46#n102
>>
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.9#n1285
>>
>>>
>>> Regards,
>>>
>>> Kevin Brace
>>> Brace Computer Laboratory blog
>>> https://bracecomputerlab.com
>>>
>>>
>>>> Sent: Sunday, October 18, 2020 at 2:04 PM
>>>> From: "Sam Ravnborg" <sam at ravnborg.org>
>>>> To: "Kevin Brace" <kevinbrace at gmx.com>
>>>> Cc: dri-devel at lists.freedesktop.org, "Dave Airlie" <airlied at redhat.com>
>>>> Subject: Re: It appears drm-next TTM cleanup broke something . . .
>>>>
>>>> Hi Kevin.
>>>>
>>>> On Sun, Oct 18, 2020 at 09:15:17PM +0200, Kevin Brace wrote:
>>>>> As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM repository a few days ago.
>>>>
>>>> I know you have been working on and off on the openchrome driver for a
>>>> long time now. Any chance we will see the driver submitted for upstream soon?
>>>>
>>>>      Sam
>>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer