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

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:

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 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

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

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

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

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

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

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

> 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. But pin+vmap (needed by generic fbcon) is implemented. cheers, Gerd

On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote: > 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.

On Wed, May 15, 2019 at 09:05:54AM +0200, Thomas Zimmermann wrote: > 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.

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.

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

On Wed, 4 Nov 2009 17:42:26 +0000 Jakob Bornecrantz <jakob at vmware.com> wrote: > Hi Jerome > > On 4 nov 2009, at 15.58, Jerome Glisse wrote: > > > > Note: For reference my issue is with cursor on old radeon hw, > > cursor must be in the next 128M from the crtc scanout buffer. We > > got issue when someone start to resize their screen at which > >

https://bugs.freedesktop.org/show_bug.cgi?id=102430 Bug ID: 102430 Summary: nv4x - memory problems when starting graphical application - logs included Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

Am 18.02.20 um 18:13 schrieb Nirmoy: > > On 2/18/20 1:44 PM, Christian K?nig wrote: >> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>> Hi >>> >>> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>>> GPU address handling is device specific and should be handle by its >>>> device >>>> driver. >>>> >>>>

Hi Am 18.02.20 um 18:13 schrieb Nirmoy: > > On 2/18/20 1:44 PM, Christian K?nig wrote: >> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>> Hi >>> >>> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>>> GPU address handling is device specific and should be handle by its >>>> device >>>> driver. >>>>