[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2016-08-31 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

Andrew Randrianasulu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #18 from Andrew Randrianasulu  ---
Fixed with mesa git, thanks Ilia!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #17 from Ben Skeggs  ---
(In reply to Ilia Mirkin from comment #14)
> (In reply to Andrew Randrianasulu from comment #13)
> > (In reply to Ilia Mirkin from comment #12)
> > > (In reply to Andrew Randrianasulu from comment #11)
> > > > "Mismatched color and zeta formats, ignoring zeta."
> > > 
> > > Yeah, as I suspected... unfortunately there's not a ton you can do besides
> > > fixing the issue. The problem is that you can't render to a 32-bit color
> > > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you
> > > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit
> > > zeta (Z24S8).
> > > 
> > > My current solution to this problem is to just not set the zeta buffer and
> > > move on with life. This leads to incorrect rendering, but at least no 
> > > hangs.
> > > 
> > > The proper solution is to have 2 depth textures that you copy to and fro 
> > > and
> > > set the "right" one for the given color format. Ideally while minimizing 
> > > the
> > > number of copies.
> > 
> > Hm, but in my case it apparently worked fine... so, may be check is
> > overrestrictive?
> > 
> > I also tried to apply this path on top of mesa version indicated above
> > ((git-93161be)
> > 
> > patch---
> > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > b/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > index fd604c2..cceedfd 100644
> > --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe,
> > (util_format_get_blocksize(fb->zsbuf->format) > 2) !=
> > (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) {
> >nv30->framebuffer.zsbuf = NULL;
> > -  debug_printf("Mismatched color and zeta formats, ignoring
> > zeta.\n");
> > +  debug_printf("Mismatched color %d and zeta %d formats, ignoring
> > zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format);
> > }
> >  }
> >  }
> > end-
> > 
> > and got this in terminal:
> > "Mismatched color 1 and zeta 16 formats, ignoring zeta."
> > 
> > This is a bit strange, this demo from ~2002 era, and apparently was  working
> > fine on older nvidia hardware. And on nouveau, until this  commit.  I will
> > retest just for making sure it doesn't flood my dmesg with errors 
> 
> You should be seeing errors about invalid values in dmesg for 0208 or some
> similar method. I'm guessing that the zeta buffer is used in such a way that
> things happen to work out, but the card doesn't really support it.
> 
> src/gallium/include/pipe/p_format.h:   PIPE_FORMAT_B8G8R8A8_UNORM  =
> 1,
> src/gallium/include/pipe/p_format.h:   PIPE_FORMAT_Z16_UNORM   =
> 16,
> 
> Not a valid combo, AFAIK.

I believe that restriction might only apply to swizzled surfaces.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-12 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #13 from Andrew Randrianasulu  ---
(In reply to Ilia Mirkin from comment #12)
> (In reply to Andrew Randrianasulu from comment #11)
> > "Mismatched color and zeta formats, ignoring zeta."
> 
> Yeah, as I suspected... unfortunately there's not a ton you can do besides
> fixing the issue. The problem is that you can't render to a 32-bit color
> format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you
> can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit
> zeta (Z24S8).
> 
> My current solution to this problem is to just not set the zeta buffer and
> move on with life. This leads to incorrect rendering, but at least no hangs.
> 
> The proper solution is to have 2 depth textures that you copy to and fro and
> set the "right" one for the given color format. Ideally while minimizing the
> number of copies.

Hm, but in my case it apparently worked fine... so, may be check is
overrestrictive?

I also tried to apply this path on top of mesa version indicated above
((git-93161be)

patch---
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c
b/src/gallium/drivers/nouveau/nv30/nv30_state.c
index fd604c2..cceedfd 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_state.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c
@@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe,
(util_format_get_blocksize(fb->zsbuf->format) > 2) !=
(util_format_get_blocksize(fb->cbufs[0]->format) > 2)) {
   nv30->framebuffer.zsbuf = NULL;
-  debug_printf("Mismatched color and zeta formats, ignoring zeta.\n");
+  debug_printf("Mismatched color %d and zeta %d formats, ignoring
zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format);
}
 }
 }
end-

and got this in terminal:
"Mismatched color 1 and zeta 16 formats, ignoring zeta."

This is a bit strange, this demo from ~2002 era, and apparently was  working
fine on older nvidia hardware. And on nouveau, until this  commit.  I will
retest just for making sure it doesn't flood my dmesg with errors 

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-12 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #14 from Ilia Mirkin  ---
(In reply to Andrew Randrianasulu from comment #13)
> (In reply to Ilia Mirkin from comment #12)
> > (In reply to Andrew Randrianasulu from comment #11)
> > > "Mismatched color and zeta formats, ignoring zeta."
> > 
> > Yeah, as I suspected... unfortunately there's not a ton you can do besides
> > fixing the issue. The problem is that you can't render to a 32-bit color
> > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you
> > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit
> > zeta (Z24S8).
> > 
> > My current solution to this problem is to just not set the zeta buffer and
> > move on with life. This leads to incorrect rendering, but at least no hangs.
> > 
> > The proper solution is to have 2 depth textures that you copy to and fro and
> > set the "right" one for the given color format. Ideally while minimizing the
> > number of copies.
> 
> Hm, but in my case it apparently worked fine... so, may be check is
> overrestrictive?
> 
> I also tried to apply this path on top of mesa version indicated above
> ((git-93161be)
> 
> patch---
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c
> b/src/gallium/drivers/nouveau/nv30/nv30_state.c
> index fd604c2..cceedfd 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c
> @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe,
> (util_format_get_blocksize(fb->zsbuf->format) > 2) !=
> (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) {
>nv30->framebuffer.zsbuf = NULL;
> -  debug_printf("Mismatched color and zeta formats, ignoring
> zeta.\n");
> +  debug_printf("Mismatched color %d and zeta %d formats, ignoring
> zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format);
> }
>  }
>  }
> end-
> 
> and got this in terminal:
> "Mismatched color 1 and zeta 16 formats, ignoring zeta."
> 
> This is a bit strange, this demo from ~2002 era, and apparently was  working
> fine on older nvidia hardware. And on nouveau, until this  commit.  I will
> retest just for making sure it doesn't flood my dmesg with errors 

You should be seeing errors about invalid values in dmesg for 0208 or some
similar method. I'm guessing that the zeta buffer is used in such a way that
things happen to work out, but the card doesn't really support it.

src/gallium/include/pipe/p_format.h:   PIPE_FORMAT_B8G8R8A8_UNORM  = 1,
src/gallium/include/pipe/p_format.h:   PIPE_FORMAT_Z16_UNORM   =
16,

Not a valid combo, AFAIK.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-12 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #16 from Andrew Randrianasulu  ---
Created attachment 118847
  --> https://bugs.freedesktop.org/attachment.cgi?id=118847=edit
dmesg, from glean run, makeCurrent tests

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-12 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #15 from Andrew Randrianasulu  ---
(In reply to Ilia Mirkin from comment #14)
> (In reply to Andrew Randrianasulu from comment #13)
> > (In reply to Ilia Mirkin from comment #12)
> > > (In reply to Andrew Randrianasulu from comment #11)
> > > > "Mismatched color and zeta formats, ignoring zeta."
> > > 
> > > Yeah, as I suspected... unfortunately there's not a ton you can do besides
> > > fixing the issue. The problem is that you can't render to a 32-bit color
> > > format (e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you
> > > can't render to a 16-bit color format (e.g. RGB565) while using a 32-bit
> > > zeta (Z24S8).
> > > 
> > > My current solution to this problem is to just not set the zeta buffer and
> > > move on with life. This leads to incorrect rendering, but at least no 
> > > hangs.
> > > 
> > > The proper solution is to have 2 depth textures that you copy to and fro 
> > > and
> > > set the "right" one for the given color format. Ideally while minimizing 
> > > the
> > > number of copies.
> > 
> > Hm, but in my case it apparently worked fine... so, may be check is
> > overrestrictive?
> > 
> > I also tried to apply this path on top of mesa version indicated above
> > ((git-93161be)
> > 
> > patch---
> > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > b/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > index fd604c2..cceedfd 100644
> > --- a/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > +++ b/src/gallium/drivers/nouveau/nv30/nv30_state.c
> > @@ -382,7 +382,7 @@ nv30_set_framebuffer_state(struct pipe_context *pipe,
> > (util_format_get_blocksize(fb->zsbuf->format) > 2) !=
> > (util_format_get_blocksize(fb->cbufs[0]->format) > 2)) {
> >nv30->framebuffer.zsbuf = NULL;
> > -  debug_printf("Mismatched color and zeta formats, ignoring
> > zeta.\n");
> > +  debug_printf("Mismatched color %d and zeta %d formats, ignoring
> > zeta.\n", fb->cbufs[0]->format, fb->zsbuf->format);
> > }
> >  }
> >  }
> > end-
> > 
> > and got this in terminal:
> > "Mismatched color 1 and zeta 16 formats, ignoring zeta."
> > 
> > This is a bit strange, this demo from ~2002 era, and apparently was  working
> > fine on older nvidia hardware. And on nouveau, until this  commit.  I will
> > retest just for making sure it doesn't flood my dmesg with errors 
> 
> You should be seeing errors about invalid values in dmesg for 0208 or some
> similar method. I'm guessing that the zeta buffer is used in such a way that
> things happen to work out, but the card doesn't really support it.
> 
> src/gallium/include/pipe/p_format.h:   PIPE_FORMAT_B8G8R8A8_UNORM  =
> 1,
> src/gallium/include/pipe/p_format.h:   PIPE_FORMAT_Z16_UNORM   =
> 16,
> 
> Not a valid combo, AFAIK.

just tried to comment  out zbuf disabling, rendering is ok, no errors o.o May
be because nv43 uses z-compression?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #11 from Andrew Randrianasulu  ---
After recompiling mesa

mesa git  commit 93161be9e7150ae5931000627833e714901cf195 -  "i965: Fix
intel_miptree_is_fast_clear_capable()"

with this command line 
 ./configure --prefix=/usr --disable-dri3 --with-gallium-drivers=nouveau
--enable-texture-float --enable-debug --with-dri-drivers=swrast

I got in terminal
--
bash-4.2$ wine GLExcess.exe 
fixme:winediag:start_process Wine Staging 1.7.51 is a testing version
containing experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com
(instead of winehq.org).
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: Fontconfig
warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from
~/.fonts.conf is deprecated.
reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
fixme:ole:RemUnknown_QueryInterface No interface for iid
{0019---c000-0046}
fixme:ole:RemUnknown_QueryInterface No interface for iid
{0019---c000-0046}
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
bash-4.2$ Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14:
reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Mismatched color and zeta formats, ignoring zeta.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
kbuildsycoca running...


important part seems to be:
"Mismatched color and zeta formats, ignoring zeta."

I also tried to disable PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT , but this not
fixed my bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #12 from Ilia Mirkin  ---
(In reply to Andrew Randrianasulu from comment #11)
> "Mismatched color and zeta formats, ignoring zeta."

Yeah, as I suspected... unfortunately there's not a ton you can do besides
fixing the issue. The problem is that you can't render to a 32-bit color format
(e.g. RGBA8) while using a 16-bit zeta (Z16), and conversely you can't render
to a 16-bit color format (e.g. RGB565) while using a 32-bit zeta (Z24S8).

My current solution to this problem is to just not set the zeta buffer and move
on with life. This leads to incorrect rendering, but at least no hangs.

The proper solution is to have 2 depth textures that you copy to and fro and
set the "right" one for the given color format. Ideally while minimizing the
number of copies.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #10 from Andrew Randrianasulu  ---
Please use this file instead, attached one was truncated :/

http://s000.tinyupload.com/index.php?file_id=94706413066309920881 (xz
compressed, uncompressed trace was ~17 mb)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #9 from Andrew Randrianasulu  ---
Created attachment 118742
  --> https://bugs.freedesktop.org/attachment.cgi?id=118742=edit
apitrace (bz2 compressed)

ok, as workaround I run apitrace from another machine (with "Intel(R)
Pentium(R) Dual  CPU  T2390  @ 1.86GHz" and infamous  RS600 integrated graphics
controller), where it worked.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #7 from Andrew Randrianasulu  ---
Older wine reacted the same (illegal instruction), so this is not something
added with new wine version.

This machine lacks SSE2, obviously ..may be apitrace silently compiles in some
SSE2+ code?

bash-4.2$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 11
model name  : Intel(R) Celeron(TM) CPU1000MHz
stepping: 1
microcode   : 0x1c
cpu MHz : 1000.051
cache size  : 256 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pse36 mmx fxsr sse
bugs:
bogomips: 2000.10
clflush size: 32
cache_alignment : 32
address sizes   : 36 bits physical, 32 bits virtual
power management:

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #8 from Andrew Randrianasulu  ---
apitrace at commit f004530b30a63c08a16d82536858600446b2abf5 ("Date:   Mon Sep
21 11:23:02 2015 +0100 
d3d10state: Dump D3D10 texture formats.")

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #6 from Andrew Randrianasulu  ---
Updating wine (to version 1.7.51-staging, from
http://www.slackware.com/~alien/slackbuilds/wine/pkg/14.1/) resulted in
correctly disabled Vsync, but rendering still broken in the same way.

Moreover, attempt to use latest apitrace (command line: 
~/src/apitrace/apitrace trace /usr/bin/wine GLExcess.exe ) only resulted in
illegal instruction (?!)

quote

apitrace: loaded into /usr/bin/wine
apitrace: loaded into /usr/bin/wine-preloader
apitrace: loaded into /usr/bin/wineserver
apitrace: loaded into /usr/bin/wine-preloader
fixme:winediag:start_process Wine Staging 1.7.51 is a testing version
containing experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com
(instead of winehq.org).
apitrace: loaded into /usr/bin/wine-preloader
apitrace: loaded into /usr/bin/wine-preloader
apitrace: loaded into /usr/bin/wine-preloader
apitrace: loaded into /usr/bin/wine-preloader
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
apitrace: loaded into /usr/bin/wine-preloader
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
fixme:ole:RemUnknown_QueryInterface No interface for iid
{0019---c000-0046}
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
apitrace: loaded into /usr/bin/wine-preloader
bash-4.2$ Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14:
reading configurations from ~/.fonts.conf is deprecated.
apitrace: loaded into /usr/bin/wine-preloader
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
apitrace: tracing to /home/guest/.wine/drive_c/Program Files/GL
Excess/wine-preloader.trace
apitrace: redirecting dlopen("libGL.so.1", 0x102)
apitrace: redirecting dlopen("libGL.so.1", 0x102)
apitrace: attempting to read configuration file:
/home/guest/.config/apitrace/gltrace.conf
wine: Unhandled illegal instruction at address 0xb75957f2 (thread 002a),
starting debugger...
apitrace: loaded into /usr/bin/wine-preloader
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated.
Unhandled exception: illegal instruction in 32-bit code (0xb75957f2).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:b75957f2 ESP:0033f978 EBP:0033f978 EFLAGS:00210282(  R- --  I S - - - )
 EAX:46240400 EBX:b777ab1c ECX:b777ab1c EDX:b6fdb89d
 ESI:7dffabc0 EDI:2802
Stack dump:
0x0033f978:  0033f9b8 b74366ab 46240400 0002
0x0033f988:  2802  b778adcc 1a4f
0x0033f998:  0004 b777ab1c 7dffabc0 b777ab1c
0x0033f9a8:  0033f9d8 1a50 b778ad60 7e8f77d0
0x0033f9b8:  0033fa08 7e883727 0de1 2802
0x0033f9c8:  46240400 1a4f  7e8f77d0
Backtrace:
=>0 0xb75957f2 (0x0033f978)
  1 0xb74366ab (0x0033f9b8)
  2 0x7e883727 glTexParameterf+0x86() in opengl32 (0x0033fa08)
  3 0x00441a5d in glxsv1.2 (+0x41a5c) (0x0033fa70)
  4 0x00441d01 in glxsv1.2 (+0x41d00) (0x0033fb78)
  5 0x004175f9 in glxsv1.2 (+0x175f8) (0x0033fbd8)
  6 0x0044c0b7 in glxsv1.2 (+0x4c0b6) (0x0033fdd0)
  7 0x004540a3 in glxsv1.2 (+0x540a2) (0x0033fe60)
  8 0x7ed06acc call_process_entry+0xb() in kernel32 (0x0033fe78)
  9 0x7ed07e31 in kernel32 (+0x47e30) (0x0033feb8)
  10 0x7ef91b00 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8)
  11 0x7ef94d1d call_thread_func+0x7c() in ntdll (0x0033ffa8)
  12 0x7ef91ade RtlRaiseException+0x21() in ntdll (0x0033ffc8)
  13 0x7ef65faf in ntdll (+0x45fae) (0x0033ffe8)
  14 0xb720c75d wine_call_on_stack+0x1c() in libwine.so.1 (0x)
  15 0xb720c81b wine_switch_to_stack+0x2a() in libwine.so.1 (0xbfc40d18)
  16 0x7ef6a474 LdrInitializeThunk+0x263() in ntdll (0xbfc40d68)
  17 0x7ed0ea43 __wine_kernel_init+0xa02() in kernel32 (0xbfc41c68)
  18 0x7ef6b45b __wine_process_init+0x19a() in ntdll (0xbfc41cf8)
  19 0xb7209ea8 wine_init+0x2c7() in libwine.so.1 (0xbfc41d58)
  20 0x7bf00fcc main+0x7b() in  (0xbfc421a8)
  21 0xb704c773 __libc_start_main+0xf2() in libc.so.6 (0x)
0xb75957f2: repe (bad)
Modules:
Module  Address Debug info  Name (78 modules)
PE34-  38f000   Deferredfmod
PE40-  5a7000   Export  glxsv1.2
PE  1000-10035000   Deferredglut32
PE  6000-6005d000   Deferredijl15
ELF 7bf0-7bf03000   Dwarf   
ELF 7d3a1000-7dacc000   Deferrednouveau_dri.so
ELF 7ddd-7ddd7000   Deferredlibdrm_nouveau.so.2
ELF 7ddd7000-7dde5000   Deferredlibudev.so.0
ELF 7dde5000-7ddef000   

[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

Andrew Randrianasulu  changed:

   What|Removed |Added

   Keywords||regression

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #5 from Andrew Randrianasulu  ---
Hm, apparently this is regression - tried few mesa versions - 10.1.6 was OK,
but 10.2.9 already broken.

Attempt to disable few new (in 10.2) extensions not fixed this.
"Mesa 10.2.9 implementation error: Trying to disable a permanently enabled
extension: GL_ARB_multi_bind" - this one can't be disabled, it seems
(commandline used  MESA_EXTENSION_OVERRIDE="-GL_ARB_multi_bind" wine
GLExcess.exe)

MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" wine GLExcess.exe - not
resulted in anything.

Apparently those two types of corruption related (no image and parts of scene 
filled with rainbow  lines) - at least they both started to appear in 10.2.9

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #1 from Andrew Randrianasulu  ---
Created attachment 118689
  --> https://bugs.freedesktop.org/attachment.cgi?id=118689=edit
correct software rendering

It shows some landscape, even if at 1 fps.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #2 from Andrew Randrianasulu  ---
Created attachment 118690
  --> https://bugs.freedesktop.org/attachment.cgi?id=118690=edit
incorrect hw rendering

with nouveau it only shows text and FPS bar - not landscape

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #3 from Andrew Randrianasulu  ---
Created attachment 118691
  --> https://bugs.freedesktop.org/attachment.cgi?id=118691=edit
dmesg

I think you can ignore locking-related warnings. But I can retry with 4.3-rc4
mainline, if you prefer (again, will need some time to compile it)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 92306] GL Excess demo renders incorrectly on nv43

2015-10-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92306

--- Comment #4 from Andrew Randrianasulu  ---
Created attachment 118692
  --> https://bugs.freedesktop.org/attachment.cgi?id=118692=edit
Another type of image corruption

Probably need its own bugreport. It always happen at same place in scene - so,
not random. Nearly looks like some garbage instead of (guess) alpha channel of
texture?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau