search for: swtnl

On 25.05.2015 21:29, Ilia Mirkin wrote: > Commit 8acaf862dfe switched things over to use TEXCOORD instead of > GENERIC, but did not update the nv30 swtnl draw paths. This teaches the > draw logic about TEXCOORD. > > Among other things, this fixes a crash in demos/arbocclude when using > swtnl. Curiously enough, the point-sprite piglit works without this. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > Cc: "...

...; On Mon, May 25, 2015 at 8:37 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 25.05.2015 21:29, Ilia Mirkin wrote: >>> Commit 8acaf862dfe switched things over to use TEXCOORD instead of >>> GENERIC, but did not update the nv30 swtnl draw paths. This teaches the >>> draw logic about TEXCOORD. >>> >>> Among other things, this fixes a crash in demos/arbocclude when using >>> swtnl. Curiously enough, the point-sprite piglit works without this. >>> >>> Signed-off-by: Ilia Mirkin...

https://bugs.freedesktop.org/show_bug.cgi?id=91986 Bug ID: 91986 Summary: Artifacts in models rendering with GeForce 6150 (NV4x chipsets) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component:

...ent version doesn't need any renouveau.xml modification at all. The "unification+fixes" branch referenced above is the one that should be tested. The "unification" branch contains just the unification, with no behavior changes, while "unification+fixes" also fixes swtnl and quad rendering, allowing to better test the unification. Some cleanups on top of the unfication are also included. That same repository also contains other branches with significant improvements on top of the unification, but I'm still not proposing them for inclusion as they need more tes...

This makes the vertex buffer go to GART, not VRAM, and redoes the mapping to not use the UNSYNCHRONIZED access (which is meaningless on a VRAM buffer anyways). While we're at it, add some flushes for VBO data. Moving the vertex buffer from VRAM to GART makes glxgears work fully with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not sure *why* moving the buffer from VRAM makes it work... perhaps something doesn't get flushed in time? However this is a single use by the GPU buffer, so STREAM seems like the correct usage semantic for it. Signed-off-by: Ilia Mirkin...

...buffer related ... >> > > Does libreoffice use llvm? I have vague recollections of there being > issues with llvm and libreoffice in the past because radeonsi uses > llvm as well. FWIW the nv30 gallium driver will only use llvm as part of 'draw' when falling back to the swtnl path. This should be extremely rare. But easy enough to build mesa with --disable-gallium-llvm to double-check (or what was the env var? DRAW_USE_LLVM=0 or something along those lines). -ilia

...fice use llvm? I have vague recollections of there being >>> issues with llvm and libreoffice in the past because radeonsi uses >>> llvm as well. >> >> >> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when >> falling back to the swtnl path. This should be extremely rare. But >> easy enough to build mesa with --disable-gallium-llvm to double-check >> (or what was the env var? DRAW_USE_LLVM=0 or something along those >> lines). > > > I've tried building with --disable-gallium-llvm, this does not help...

Most Gallium drivers support nested mapping by using a reference count. We don't, and swtnl fallback triggers an error due to this. This patch adds this support in libdrm. --- nouveau/nouveau_bo.c | 8 +++++++- nouveau/nouveau_private.h | 1 + 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/nouveau/nouveau_bo.c b/nouveau/nouveau_bo.c index 10cc8a6..c1a9843 1006...

Hi, I'm trying to install War3 Roc+TFT+patch 1.17 I succeded the installation. but when I starrtt the game, I got the main menu but image is blinking and mouse cursor is very slow (so I don't try to play) My system is a Fedora Core 3 / 2.6.10 and lastest wine rpm from winehq Here is wine log: > fixme:user:EnumDisplayDevicesA ((nil),0,0x67f9e4,0x00000000), stub! >

https://bugs.freedesktop.org/show_bug.cgi?id=56474 Priority: medium Bug ID: 56474 Assignee: nouveau at lists.freedesktop.org Summary: 3D app segfaults on NV46 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: 1o5g4r8o at gmail.com Hardware: x86 (IA32) Status: NEW

Hi, On 27-08-15 15:46, Marek Olšák wrote: > On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi All, >> >> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089 >> >> I made a apitrace recording of the a single slide transition >> animation, and since I suspected memory corruption replayed >> it

...;>>> issues with llvm and libreoffice in the past because radeonsi uses >>>>> llvm as well. >>>> >>>> >>>> >>>> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when >>>> falling back to the swtnl path. This should be extremely rare. But >>>> easy enough to build mesa with --disable-gallium-llvm to double-check >>>> (or what was the env var? DRAW_USE_LLVM=0 or something along those >>>> lines). >>> >>> >>> >>> I've t...

https://bugs.freedesktop.org/show_bug.cgi?id=95095 Bug ID: 95095 Summary: NV46 (G72) Full screen artifacts in Freespace 2 SW OT mod Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +++++++++++++