search for: garts

I am trying to figure out why the ttm_bo_vm_fault is stitching pages from the GART instead of the pages allocated via DRM_NOUVEAU_GEM_NEW. And also why OUR_RINGp is writing 16, 256 and 512 bytes of zero filled data *1 in the GART? Perhaps I should mention that I know _why_ it is taking the pages from the GART and giving them to the userland - but I don't know if that is correct way of doing

On 2020-05-20 4:43 p.m., Christian K?nig wrote: > Am 13.05.20 um 13:03 schrieb Christian K?nig: >> Unfortunately AGP is still to widely used as we could just drop >> support for using its GART. >> >> Not using the AGP GART also doesn't mean a loss in functionality since >> drivers will just fallback to the driver specific PCI GART. >> >> For now

On Wed, May 20, 2020 at 10:43 AM Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > Am 13.05.20 um 13:03 schrieb Christian K?nig: > > Unfortunately AGP is still to widely used as we could just drop support for using its GART. > > > > Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver

Hey everyone, I realize that people asking about PCI passthrough has been thoroughly beaten to death many a time, however I couldn''t find the answer to these questions anywhere (and I''d really like to know :P) so please just bare with me. I know the GART built into AMD chipsets can act as a "mini IOMMU" and do DMA translation but not protection/isolation. However,

Am 20.05.20 um 18:25 schrieb Michel D?nzer: > On 2020-05-20 4:43 p.m., Christian K?nig wrote: >> Am 13.05.20 um 13:03 schrieb Christian K?nig: >>> Unfortunately AGP is still to widely used as we could just drop >>> support for using its GART. >>> >>> Not using the AGP GART also doesn't mean a loss in functionality since >>> drivers will

Am 20.05.20 um 18:18 schrieb Alex Deucher: > On Wed, May 20, 2020 at 10:43 AM Christian K?nig > <ckoenig.leichtzumerken at gmail.com> wrote: >> Am 13.05.20 um 13:03 schrieb Christian K?nig: >>> Unfortunately AGP is still to widely used as we could just drop support for using its GART. >>> >>> Not using the AGP GART also doesn't mean a loss in

Unfortunately AGP is still to widely used as we could just drop support for using its GART. Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver specific PCI GART. For now just deprecate the code and don't enable the AGP GART in TTM even when general AGP support is available. Please comment, Christian.

On Tue, May 12, 2020 at 4:16 AM Michel D?nzer <michel at daenzer.net> wrote: > > On 2020-05-11 10:12 p.m., Alex Deucher wrote: > > On Mon, May 11, 2020 at 1:17 PM Christian K?nig > > <ckoenig.leichtzumerken at gmail.com> wrote: > >> > >> AGP is deprecated for 10+ years now and not used any more on modern hardware. > >> > >> Old

On Tue, May 12, 2020 at 4:52 PM Roy Spliet <nouveau at spliet.org> wrote: > > Op 12-05-2020 om 14:36 schreef Alex Deucher: > > On Tue, May 12, 2020 at 4:16 AM Michel D?nzer <michel at daenzer.net> wrote: > >> > >> On 2020-05-11 10:12 p.m., Alex Deucher wrote: > >>> On Mon, May 11, 2020 at 1:17 PM Christian K?nig > >>>

Am 13.05.20 um 13:03 schrieb Christian K?nig: > Unfortunately AGP is still to widely used as we could just drop support for using its GART. > > Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver specific PCI GART. > > For now just deprecate the code and don't enable the AGP GART in TTM even when general AGP support

Hi Nouveau folks, I've been encountering some corruption on pixmaps for a while now, and it seems like the problem comes from the DFS/UTS (Download From Screen / Upload To Screen). In fact, I'm pretty sure the problem comes from there as screenshots are garbled and so does a few more things. I may have time to dig this up, where should I start, is there some documentation on the NVS

What does the following EDAC problem means? The machine is a AMD 64bit box running Centos 5. It looks like some problems aroung AMD DRAM Memory controller. But what does it really mean b/c most of my AMD boxes has these messages in /var/log/messages. Please help. ... Aug 1 23:29:40 ccn128 kernel: EDAC MC: Ver: 2.0.1 Jun 12 2007 Aug 1 23:29:40 ccn128 kernel: EDAC MC0: Giving out device to

Most graphics cards nowadays have a multiple of this limit as their vram, so limiting GART doesn't seem to make much sense. Signed-off-by: Maarten >Lnkhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 3a5e19a..41ddecd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++

I looked a bit more into the problem of vertex corruption with GART vertex buffers that disappears putting the buffers in VRAM that I'm experiencing on my card. The system I'm seeing this on is a Dell Inspiron 9400 notebook with a GeForce Go 7900 GS on a PCI Express Intel i945 chipset. First, I've looked into the behavior of the nVidia driver: 1. On all NV3x and NV4x traces, and my

This patch enlarges the PCI GART aperture to 512 MB. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. In particular, if RAMIN is less than 1MB, a 512MB aperture won't fit. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_sgdma.c

Changes in v2: - Compute size based on ramin_rsvd_size This patch enlarges the PCI GART aperture to 512 MB, or the space covered by a DMA object filling half RAMIN. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. Could anyone with an nv04 test whether this doesn't break there?

Keeping it in VRAM wastes CPU time, because cursor_set ioctl reads handed BO back to RAM, just to write it to actual cursor BO. Here (nv92/core i7), this patch decreases overall cpu usage of drmmode_load_cursor_argb from 4.6ms to ~90us and lets nv50_crtc_cursor_set disappear from perf traces. --- I considered accelerating kernel-side copying with GPU, but it turns out that: - it's slower

Am 12.05.20 um 23:12 schrieb Alex Deucher: > On Tue, May 12, 2020 at 4:52 PM Roy Spliet <nouveau at spliet.org> wrote: >> Op 12-05-2020 om 14:36 schreef Alex Deucher: >>> On Tue, May 12, 2020 at 4:16 AM Michel D?nzer <michel at daenzer.net> wrote: >>>> On 2020-05-11 10:12 p.m., Alex Deucher wrote: >>>>> On Mon, May 11, 2020 at 1:17 PM

Op 12-05-2020 om 14:36 schreef Alex Deucher: > On Tue, May 12, 2020 at 4:16 AM Michel D?nzer <michel at daenzer.net> wrote: >> >> On 2020-05-11 10:12 p.m., Alex Deucher wrote: >>> On Mon, May 11, 2020 at 1:17 PM Christian K?nig >>> <ckoenig.leichtzumerken at gmail.com> wrote: >>>> >>>> AGP is deprecated for 10+ years now and not

If you want to access gart as linear, don't specify a non-zero storage type. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_mem.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c index 5b498ea..4642ea7 100644 ---