similar to: [PATCH] gr/nv3x: add 0x0597 kelvin 3d class support

I just noticed these messages in my logs : modprobe:1998 conflicting memory types e8000000-e8010000 uncached-minus<->write-combining reserve_memtype failed 0xe8000000-0xe8010000, track uncached-minus, req uncached-minus ioremap reserve_memtype failed -16 Xorg:5078 conflicting memory types e8000000-e8010000 uncached-minus<->write-combining reserve_memtype failed 0xe8000000-0xe8010000,

--- man/nouveau.man | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 7c72907..a8dfacd 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -13,7 +13,7 @@ nouveau \- NVIDIA video driver .fi .SH DESCRIPTION .B nouveau -is an __xservername__ driver for NVIDIA video cards. The driver supports 2D +is an

Another apparently harmless message.. But I find it quite curious. Especially that they seem pretty harmful in the case of http://bugs.freedesktop.org/show_bug.cgi?id=25393 So my setup is nv35 with a 19' CRT screen connected to vga output. I get random occurrences of this message : [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 161 [drm:edid_is_valid] *ERROR* Raw EDID:

I was wondering if there is actually someone willing to mentor this: > Implement nouveau TV-out support. This will require picking up a card > or two and figuring out how TV encoding works on them (integrated, > separate chip, etc.) then how to program the chip (by reverse > engineering, or because the chip is documented). Then the student > should implement TV-out support as part

http://bugs.freedesktop.org/show_bug.cgi?id=12051 Summary: inserting nouveau.ko failed with kernel 2.6.17 since commit 8a4d7f34d9c0182c466518c6f413d9a039db402d Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium

First some data errors I get with both nv20 exa and nv20 dri/mesa. 1. RT_FORMAT LINEAR + X8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000105 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000105 LINEAR + A8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000108 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000108 The only value I found in renouveau dump

This will allow the nouveau module to only include support for nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination). Only compiling one of the card types at a time reduces the size of the nouveau module, from 1.3M to 700-800K, depending on the type (including symbols/etc). It should also yield a reduction in compile time as a lot fewer files are compiled. Here are the sizes

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/drivers/nvfx/nvfx_state_emit.c b/src/gallium/drivers/nvfx/nvfx_state_emit.c index

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 +++

On 30/07/13 00:05, Ilia Mirkin wrote: > 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 > ---

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]:

May I ask why you're doing 512x512 instead of 1024x1024? These are already scaled up coordinates, so 1024x1024 should work no? Or is it because of the seams on the edges? Do those not also appear with 512x512 or does 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

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

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

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> --- Changes in v2: -Use 1024x1024 blocks -Use the sifm on both nv3x

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]:

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > > On 28-08-15 11:02, Ilia Mirkin wrote: >> >> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: >>> >>> Hi, >>> >>> On 27-08-15 20:19, Ilia Mirkin wrote: >>>> >>>>

On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > On 27-08-15 20:19, Ilia Mirkin wrote: >> >> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher at gmail.com> >> wrote: > > > <snip> > >>>>>> 2) Since the glretrace does work outside of libreoffice impress, I

- Added flush notify functions for NV30 and NV40. - NV30 and NV40 need testing (check for regressions). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 47 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++-- src/gallium/drivers/nv30/nv30_context.c | 3 ++ src/gallium/drivers/nv30/nv30_context.h | 1 +