similar to: [PATCH 00/15] Share TTM code among framebuffer drivers

On Tue, Apr 16, 2019 at 12:05 PM Koenig, Christian <Christian.Koenig at amd.com> wrote: > > Am 15.04.19 um 21:17 schrieb Daniel Vetter: > > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > >> Hi > >> > >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: > >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200,

On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > Hi > > Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > > Hi, > > > >> If not for TTM, what would be the alternative? One VMA manager per > >> memory region per device? > > > > Depends pretty much on the device. > > > > The cirrus is a display device with

Am 15.04.19 um 21:17 schrieb Daniel Vetter: > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> Hi >> >> Am 15.04.19 um 17:54 schrieb Daniel Vetter: >>> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: >>>> Hi >>>> >>>> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com:

Hi, > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Depends pretty much on the device. The cirrus is a display device with only 4 MB of vram. You can't fit much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% of the video memory already. Which is why the cirrus driver (before the rewrite) had to migrate buffers from/to

Hi, > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Depends pretty much on the device. The cirrus is a display device with only 4 MB of vram. You can't fit much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% of the video memory already. Which is why the cirrus driver (before the rewrite) had to migrate buffers from/to

Am 20.05.19 um 18:26 schrieb Daniel Vetter: > [CAUTION: External Email] > > On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote: >> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: >>> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the >>> GEM VRAM pin/unpin functions that do not reserve the BO during validation.

On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the > GEM VRAM pin/unpin functions that do not reserve the BO during validation. > The mgag200 driver requires this behavior for its cursor handling. The > patch also converts the driver to use the new interfaces. > > Signed-off-by: Thomas

On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the > GEM VRAM pin/unpin functions that do not reserve the BO during validation. > The mgag200 driver requires this behavior for its cursor handling. The > patch also converts the driver to use the new interfaces. > > Signed-off-by: Thomas

Hi, most of this patch set still needs reviews. If it's too large for merging or reviewing at once, I could move the driver changes into separate patch sets. The vbox driver's changes have been accepted by Hans already. So only keeping the core changes plus vbox would be an option. Best regards Thomas Am 08.05.19 um 10:26 schrieb Thomas Zimmermann: > Several simple framebuffer

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

On Tue, 9 Apr 2019 at 17:12, kraxel at redhat.com <kraxel at redhat.com> wrote: > > Hi, > > > If not for TTM, what would be the alternative? One VMA manager per > > memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there. A single 1024x768 @ 24bpp

Well first problem is I'm not sure if that is a good idea. Essentially we want to get rid of TTM in the long run. On the other hand this work might aid with that goal, so it might be worth a try. Second is that this might actually not work of hand. The problem is here: > + /* TODO: This test used to be performed by drivers, but can > + * this actually happen? If so, should we put

Hi Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: >> GEM VRAM could implement PRIME helpers, which would allow for using >> the generic fbcon. > > bochs_gem_prime_*() functions with this series applied look like you can > just rename them & move over to vram helpers. > > It's not a full prime implementation, specifically actual export/import > isn't there.

Hi Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: >> GEM VRAM could implement PRIME helpers, which would allow for using >> the generic fbcon. > > bochs_gem_prime_*() functions with this series applied look like you can > just rename them & move over to vram helpers. > > It's not a full prime implementation, specifically actual export/import > isn't there.

On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote: > On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: > > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the > > GEM VRAM pin/unpin functions that do not reserve the BO during validation. > > The mgag200 driver requires this behavior for its cursor handling. The > >

Am 08.04.19 um 13:59 schrieb Thomas Zimmermann: [SNIP] > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Since everybody vital seems to be on this mail thread anyway, let's use it a bit for brain storming what a possible replacement for TTM should look like. Well for simple drivers like qemu/bochs and cirrus the answer is to not use it

On Mon, May 06, 2019 at 10:26:30AM +0200, Thomas Zimmermann wrote: > Several simple framebuffer drivers copy most of the TTM code from each > other. The implementation is always the same; except for the name of > some data structures. > > As recently discussed, this patch set provides generic memory-management > code for simple framebuffers with dedicated video memory. It

The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the GEM VRAM pin/unpin functions that do not reserve the BO during validation. The mgag200 driver requires this behavior for its cursor handling. The patch also converts the driver to use the new interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_gem_vram_helper.c | 75

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same