search for: nv3x

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: > On nv3x we will likely end up using the cpu to do color resolving for msaa > blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fallback won't do scaled, so it's stuck with SIFM or assert(false). Which isn't great, but... it's what the HW does. I...

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Change...

...s it sample outside of the box? Separately, why not use this approach on nv40 as well? I can't imagine the blitter would be faster... does this result in lower quality? On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdegoede at redhat.com> wrote: > We do not have a generic blitter on nv3x cards, so we must use the > sifm object for color resolving. > > This commit divides the sources and dest surfaces in to tiles which > match the constraints of the sifm object, so that color resolving > will work properly on nv3x cards. > > Signed-off-by: Hans de Goede <hdeg...

Apparently nv3x needs some curde hacks to work properly. This is clearly not the right fix, but it's the behaviour of the old code and fixes regressions seen by users. --- src/gallium/drivers/nvfx/nvfx_state_emit.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/gallium/drive...

...ice(priv)->chipset >= 0x40 && nv44_graph_class(priv)) > + nv_wr32(priv, 0x00b220, 0x00000044); > + else > + nv_wr32(priv, 0x00b220, 0x00000031); Might be a nitpicking too much, but I believe the check makes more sense inside nv44_graph_class(), despite that this is the only nv3x context that uses it Emil > nv_wr32(priv, 0x00b300, 0x02001ec1); > nv_mask(priv, 0x00b32c, 0x00000001, 0x00000001); > >

Tested on a NV34. There are reports of this also working on the other nv3x chips. Largely useful for testing software written for NV2x without having the actual hardware available. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not sure whether nv30/nv35 have 0x0097 or 0x0597. Even though their respective class numbers are lower, it's still believabl...

...p, > this is not really surprising since on Fedora both libreoffice and > mesa use the system llvm, so there should be no problems with them > expecting different llvm versions. > > I've done some further debugging adding some debug printf-s to the > texture creation paths for nv3x, this bit is interesting, glretrace > does: > > nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0 > nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1 > target 2 > > So it gets a texture from a handle, which I believe is the child-window &...

On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi Ilia > > On 31-08-15 18:30, Ilia Mirkin wrote: >> >> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: > > > <snip> > > >>> Interestingly enough nv30_screen_get_param returns 0 for >>>

Hi All, I've recently acquired a nvs280 card, which is a nv34 gpu based card with a pci-e bridge on the card, this way I can test nv3x problems without needing an agp motherboard. One thing which stands out with this card is that it drivers my dvi lcd monitor at 1680x1050 instead of its native 1920x1080. Is this due to a known limitation on the display pipeline of these cards / nv34 gpu-s. Or is this more likely a bug somewhere...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c index 9f7c7d5..c190043 100644 --- a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c +++

This should fix some unaligned access warnings. This is also likely to fix non-descript issues on nv30/nv34 as a result of incorrect channel setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/nv30.c | 4 ++-- drm/nouveau/nvkm/engine/gr/nv34.c | 4 ++-- 2 files changed, 4 insertions(+), 4

For all these patches I'd say: testers are welcome. The first three patches seem good enough to push as we speak IMHO (so if you agree, go ahead!), whereas for the fourth I don't know if this is the desired way to fix. The result of these four patches is that NV34 gives a nearly-correct desktop experience, where only some fading animations appear broken. It's quite useable now! [1/4]:

...nce on Fedora both libreoffice and >>> mesa use the system llvm, so there should be no problems with them >>> expecting different llvm versions. >>> >>> I've done some further debugging adding some debug printf-s to the >>> texture creation paths for nv3x, this bit is interesting, glretrace >>> does: >>> >>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0 >>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1 >>> target 2 >>> >>> So it gets a text...

The sifm object has a limit of 1024x1024 for its input size and 2048x2048 for its output. The code checking this was trying to be clever resulting in it seeing a surface of e.g 1024x256 being outside of the input size limit. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 4 ++-- 1 file changed, 2

A reworked version of 3 out of 4 patches mentioned earlier. [1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords. [2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug [3/4]:

Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely clear to me what the process is for getting (nouveau) mesa patches merged. Should I request commit rights, and push my own patches once they have been reviewed ? Regards, Hans

...ertex 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 system, vertex buffers are always put in VRAM (renouveau uses GL_STATIC_DRAW) 2. On my system all vertex object usage flags still cause the vertex buffer to be put in VRAM 3. On my system GL_NV_vertex_range causes the use of a GART vertex buffer, and seems the only way to do...

...01.766961] nouveau E[soffice.bin[3785]] validating bo list > [ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12 > > After which the program using the msaa visual freezes, and eventually > the entire system freezes. Disable msaa until this is fixed. > > This happens on both nv3x and nv4x cards. Ugh. This is aka "you ran out of vram, goodbye". We don't really handle that case extremely well. I feel really bad doing this :( The issue is anachronistic applications like soffice that don't keep with the limitations of GPUs of the days of yore. So we end up pe...

On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher at gmail.com> wrote: > On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> 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: >>>>

...(NV04) [ 140.087] RIVA TNT2 (NV05) [ 140.087] GeForce 256 (NV10) [ 140.087] GeForce 2 (NV11, NV15) [ 140.087] GeForce 4MX (NV17, NV18) [ 140.087] GeForce 3 (NV20) [ 140.087] GeForce 4Ti (NV25, NV28) [ 140.088] GeForce FX (NV3x) [ 140.088] GeForce 6 (NV4x) [ 140.088] GeForce 7 (G7x) [ 140.088] GeForce 8 (G8x) [ 140.088] GeForce GTX 200 (NVA0) [ 140.088] GeForce GTX 400 (NVC0) [ 140.088] (II) modesetting: Driver for Modesetting Kernel Drivers: kms >From /proc/cmdline rdblac...