https://bugs.freedesktop.org/show_bug.cgi?id=90276
--- Comment #19 from Arthur Heymans ---
Ok there are still crashes but they tend to happen less easier/fast.
Applications that once produced a reproducible instant crashes, now crashes
with same errors after ~30min or more. (also works on more re
https://bugs.freedesktop.org/show_bug.cgi?id=90276
--- Comment #18 from Ilia Mirkin ---
(In reply to Arthur Heymans from comment #17)
> Reversing 3d9e3921f4d77bcaeea913c48b894d1208f0cb06 solves the problem.
>
> Howerever c39f472e9f14e49a9bc091977ced0ec45fc00c57 changes some names so I
> don't kn
https://bugs.freedesktop.org/show_bug.cgi?id=90276
--- Comment #17 from Arthur Heymans ---
Reversing 3d9e3921f4d77bcaeea913c48b894d1208f0cb06 solves the problem.
Howerever c39f472e9f14e49a9bc091977ced0ec45fc00c57 changes some names so I
don't know what to for recent kernels.
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #9 from Marcin Slusarz ---
Yes, this fixes gun rendering.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #8 from Ilia Mirkin ---
This patch should get it going, but I don't think I want to commit it as-is.
This gets me the same overly-lit rendering as r600, so any remaining issues are
in the st. Should probably investigate what the "real
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #7 from Ilia Mirkin ---
OK, I think I see what's happening... the sequence goes something like this:
3: mov u32 %r438 0x3f80 (0)
16: mov u32 $r0 %r445 (0)
17: mov u32 $r1 %r452 (0)
18: call abs BUILTIN:1 (0)
19: mov u32 %r
https://bugs.freedesktop.org/show_bug.cgi?id=91598
--- Comment #13 from David March ---
Just wanted to add that this also can be replicated on KDE4 (I have since
downgraded to get a usable system) as well (although far more rare). In this
case it is a freeze (sometimes indefinite) but I do not n
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #6 from Marcin Slusarz ---
Hmm, I'm not sure anymore which lighting is the correct one...
One more trace with better view:
http://people.freedesktop.org/~mslusarz/ShadowWarrior.bin.x86.2.trace.xz (181
MB)
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #5 from Ilia Mirkin ---
Created attachment 118107
--> https://bugs.freedesktop.org/attachment.cgi?id=118107&action=edit
vertex shader that fails to compile
Don't know if this is *the* issue, but it's certainly *an* issue. A little
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #4 from Ilia Mirkin ---
Probably relevant to the nouveau-specific issue:
ERROR: no viable spill candidates left
I bet the end result is black, which explains those spots. Haven't done more
debugging on that yet.
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #3 from Ilia Mirkin ---
(In reply to Ilia Mirkin from comment #2)
> GlennK reproduced the same issue on r600, so it's most likely a st/mesa bug.
Errr... two issues. One is the lighting issue, which also happens on r600.
Another is th
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #2 from Ilia Mirkin ---
GlennK reproduced the same issue on r600, so it's most likely a st/mesa bug.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_
The set of variable defs does not need to be ordered in any way, and
removing/adding elements is a fairly common operation in various
optimization passes.
This shortens runtime of piglit test fp-long-alu to ~11s from ~22s
No piglit regressions observed on nvc0!
Signed-off-by: Tobias Klausmann
--
https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #1 from Marcin Slusarz ---
Created attachment 118103
--> https://bugs.freedesktop.org/attachment.cgi?id=118103&action=edit
Shadow Warrior on Intel
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are
https://bugs.freedesktop.org/show_bug.cgi?id=91895
Marcin Slusarz changed:
What|Removed |Added
Attachment #118102|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=91895
Bug ID: 91895
Summary: [nve7] Shadow Warrior: black gun & messed up colors
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=91551
--- Comment #8 from Mauro Rossi ---
Hi,
I tried to apply the two patches proposed by jr, in
https://bugs.freedesktop.org/show_bug.cgi?id=90887 thread,
built patched nouveau_dri.so i386 target and checked about the artifacts on
FS2open mod.
In
BUG: unable to handle kernel paging request at c90003161018
IP: [] reservation_object_wait_timeout_rcu+0x35c/0x580
PGD 13a89a067 PUD 13a89b067 PMD 136735067 PTE 0
Oops: [#1] PREEMPT SMP
Modules linked in: ctr ccm rfcomm bnep arc4 iwldvm mac80211 binfmt_misc
iwlwifi cfg80211 rtsx_usb
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
https://bugs.freedesktop.org/show_bug.cgi?id=91890
--- Comment #5 from Marcin Slusarz ---
This patch resolves both blurriness and DATA_ERRORs.
Thanks!
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_
Indications are that if the colormask indicates a single bit set on
fermi, that value will always be read from $r0 instead of a potentially
higher register (if e.g. green is set). Not to upset the counting logic,
always set the header up with a full color mask for each RT.
Fixes the following pigl
21 matches
Mail list logo