Re: [PATCH 00/15] Share TTM code among framebuffer drivers
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 vram on every page flip[1]. Which is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the vram any more. gem objects are managed with the shmem helpers instead and the active framebuffer is blitted to vram. The qemu stdvga (bochs driver) has 16 MB vram by default and can be configured to have up to 256 MB. Plenty of room even for multiple 4k framebuffers if needed. So for the bochs driver all the ttm bo migration logic is not needed, it could just store everything in vram. A set of drm_gem_vram_* helpers would do the job for bochs. I'd expect the same applies to the vbox driver. Dunno about the other drm drivers and the fbdev drivers you plan to migrate over. cheers, Gerd [1] Note: The page-flip migration logic is present in some of the other drivers too, not sure whenever they actually need that due to being low on vram too or whenever they just copied the old cirrus code ... [2] The other reason is that this allow to convert formats at blit time, which helps to deal with some cirrus hardware limitations. ___ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Hi, > > The qemu stdvga (bochs driver) has 16 MB vram by default and can be > > configured to have up to 256 MB. Plenty of room even for multiple 4k > > framebuffers if needed. So for the bochs driver all the ttm bo > > migration logic is not needed, it could just store everything in vram. > > To clarify I assume you mean it doesn't need the migrate each bo > logic, but it still needs the when VRAM fills up migrate stuff logic. I think even the "when vram fills up" logic isn't that important. The driver has no acceleration so there is nothing to store beside dumb framebuffers, and the vram size can easily be increased if needed. cheers, Gerd ___ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: Fix the ID mismatch error
On Thu, Feb 21, 2019 at 12:33:03AM +, Alistair Francis wrote: > When running RISC-V QEMU with the Bochs device attached via PCIe the > probe of the Bochs device fails with: > [drm:bochs_hw_init] *ERROR* ID mismatch > > This was introduced by this commit: > 7780eb9ce8 bochs: convert to drm_dev_register > > To fix the error we ensure that pci_enable_device() is called before > bochs_load(). > > Signed-off-by: Alistair Francis > Reported-by: David Abdurachmanov Pushed to drm-misc-fixes. thanks, Gerd ___ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: Fix the ID mismatch error
On Thu, Feb 21, 2019 at 10:44:06AM -0800, Alistair Francis wrote: > On Thu, Feb 21, 2019 at 3:52 AM [email protected] wrote: > > > > On Thu, Feb 21, 2019 at 12:33:03AM +, Alistair Francis wrote: > > > When running RISC-V QEMU with the Bochs device attached via PCIe the > > > probe of the Bochs device fails with: > > > [drm:bochs_hw_init] *ERROR* ID mismatch > > > > > > This was introduced by this commit: > > > 7780eb9ce8 bochs: convert to drm_dev_register > > > > > > To fix the error we ensure that pci_enable_device() is called before > > > bochs_load(). > > > > > > Signed-off-by: Alistair Francis > > > Reported-by: David Abdurachmanov > > > > Pushed to drm-misc-fixes. > > Thanks. Any chance this will make it into 5.0? Hmm, we are damn close to the release, not sure there will be one more drm-fixes pull req. But I've added a proper Fixes: tag, so even if the patch misses the boat it should land in the stable branches shortly thereafter. cheers, Gerd ___ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/vmwgfx: switch to own vma manager
On Thu, Sep 05, 2019 at 08:31:34AM +, Thomas Hellstrom wrote: > On Thu, 2019-09-05 at 09:05 +0200, Gerd Hoffmann wrote: > > Add struct drm_vma_offset_manager to vma_private, initialize it and > > pass it to ttm_bo_device_init(). > > > > With this in place the last user of ttm's embedded vma offset manager > > is gone and we can remove it (in a separate patch). > > > > Signed-off-by: Gerd Hoffmann > > --- > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +- > > 2 files changed, 6 insertions(+), 1 deletion(-) > > > > > > Reviewed-by: Thomas Hellström > > I assume this will be merged through drm-misc? Yes, that is the plan (after collecting acks for all drivers). cheers, Gerd
Re: [PATCH] drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages
On Wed, Sep 19, 2018 at 07:09:53AM +, An, Jiandi wrote: > With virtio gpu ttm-pages being dma mapped, dma sync is needed when > swiotlb is used as bounce buffers, before TRANSFER_TO_HOST_2D/3D > commands are sent. Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
