search for: vram

On 19 June 2015 at 21:51, Martin Peres <martin.peres at free.fr> wrote: > On 19/06/2015 13:02, Alexandre Courbot wrote: >> >> New revision of this patchset that prevents VRAM objects from being >> allocated on VRAM-less systems like Tegra. This is required for Mesa >> to work on such systems. >> >> Changes since v2: >> - Use vram_size to detect systems without VRAM and set the correct >> domain instead of expecting each chip to set...

...ts are mixed. Maybe be consistent and use u32, s32 everywhere? I did not read the code carefully enough to understand it. I cannot give a r-b or a-b - as I feel I need to understand it to do so. Sam On Mon, Apr 29, 2019 at 04:43:23PM +0200, Thomas Zimmermann wrote: > The type |struct drm_gem_vram_object| implements a GEM object for simple > framebuffer devices with dedicated video memory. The BO is either located > in VRAM or system memory. > > The implementation has been created from the respective code in ast, > bochs and mgag200. These drivers copy their implementation fr...

...ts are mixed. Maybe be consistent and use u32, s32 everywhere? I did not read the code carefully enough to understand it. I cannot give a r-b or a-b - as I feel I need to understand it to do so. Sam On Mon, Apr 29, 2019 at 04:43:23PM +0200, Thomas Zimmermann wrote: > The type |struct drm_gem_vram_object| implements a GEM object for simple > framebuffer devices with dedicated video memory. The BO is either located > in VRAM or system memory. > > The implementation has been created from the respective code in ast, > bochs and mgag200. These drivers copy their implementation fr...

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

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

...Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: shiningxc at gmail.com QAContact: xorg-team at lists.x.org Created an attachment (id=48831) --> (https://bugs.freedesktop.org/attachment.cgi?id=48831) possible workaround for 64mb vram cards Large images in Firefox only show up as black rectangles. At the same time, the following errors appear in dmesg : [ 590.075369] [drm] nouveau 0000:01:00.0: fail ttm_validate [ 590.075371] [drm] nouveau 0000:01:00.0: validate vram_list [ 590.075374] [drm] nouveau 0000:01:00.0: validate:...

...ieb 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 vram on every page flip[1]. Which > > is one[2] of the reaso...

On Mon, Oct 27, 2014 at 6:34 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > GK20A does not have dedicated VRAM, therefore allocating in VRAM can be > sub-optimal and sometimes even harmful. Set its VRAM domain to > NOUVEAU_BO_GART so all objects are allocated in system memory. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > src/gallium/drivers/nouveau/nvc0/nvc0...

VRAM MM and GEM VRAM are only used with each other. This patch set moves VRAM MM into GEM VRAM source files and cleans up the helper's public interface. Thomas Zimmermann (4): drm/vram: Move VRAM memory manager to GEM VRAM implementation drm/vram: Have VRAM MM call GEM VRAM functions directly...

...<maarten.lankhorst at canonical.com> wrote: >> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >> VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to >> get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. > It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size. > > What configuration does the buffer that's getting moved here have > exactly? The placement restriction isn't necessary on GF8, the rest > of the restrictions ma...

...t;> > >>>> 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 > &gt...

...t;> > >>>> 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 > &gt...

The type |struct drm_gem_vram_object| implements a GEM object for simple framebuffer devices with dedicated video memory. The BO is either located in VRAM or system memory. The implementation has been created from the respective code in ast, bochs and mgag200. These drivers copy their implementation from each other; except for...

...with dedicated video memory. It further > converts the respective drivers to the generic code. The shared code > is basically the same implementation as the one copied among individual > drivers. > > The patch set contains two major changes: first, it introduces > |struct drm_gem_vram_object| and helpers (GEM VRAM). It's a GEM object > that is backed by VRAM. The type's purpose is somewhat similar to > |struct drm_gem_{cma, shmem}_object|: it provides an commom implementation > that handles all the basic cases. Second, the patch set introduces > |struct drm_v...

The type |struct drm_gem_vram_object| implements a GEM object for simple framebuffer devices with dedicated video memory. The BO is either located in VRAM or system memory. The implementation has been created from the respective code in ast, bochs and mgag200. These drivers copy their implementation from each other; except for...

The VRAM MM memory manager is a helper library that manages dedicated video memory of simple framebuffer devices. It is supported to be used with struct drm_gem_vram_object, but does not depend on it. The implementation is based on the respective code from ast, bochs, and mgag200. These drivers share the e...

VRAM MM and GEM VRAM are only used with each other. This patch set moves VRAM MM into GEM VRAM source files and cleans up the helper's public interface. Version 2 of the patch set doesn't contain functional changes. I'm reposting due to the rebasing onto the debugfs patches. v2: * updated...

Some newer chips have trouble coming up, and we get bad MMIO reads from them, like 0xbadf100. This ends up translating into crazy amounts of VRAM, which destroys all sorts of other logic down the line. Instead, fail device init. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at kernel.org --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/fb/ram...

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

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