Hi On 21.10.20 10:14, Daniel Vetter wrote: > On Wed, Oct 21, 2020 at 10:03 AM Thomas Zimmermann <tzimmerm...@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" <s...@ravnborg.org> >>>> To: "Kevin Brace" <kevinbr...@gmx.com> >>>> Cc: dri-devel@lists.freedesktop.org, "Dave Airlie" <airl...@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@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@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
