---
So... this fixes a whole bunch of EXT_framebuffer_multisample tests, and the
ones that still fail appear to do so due to some resolve error, rather than
some "this is the wrong image" type errors. Perhaps it needs a 2d-style "move
coordinates over a sub-texel" logic. But I'm unclear what these
This logic is borrowed from the radeon code. The transfer logic will
only get called for PIPE_BUFFER resources, so it shouldn't be necessary
to worry about them becoming render targets.
Signed-off-by: Ilia Mirkin
---
This was re-tested by someone on both nv50 and nvc0. The performance gain
remai
nouveau_fence_wait has the expectation that an external entity is
holding onto the fence being waited on, not that it is merely held onto
by the current pointer. Fixes a use-after-free in nouveau_fence_wait
when used on the screen's current fence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cg
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #41 from Ilia Mirkin ---
Created attachment 95205
--> https://bugs.freedesktop.org/attachment.cgi?id=95205&action=edit
patch to fix fence wait on screen destroy
This fixes the valgrind warning for me, and makes logical sense (alway
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #40 from Ilia Mirkin ---
OK, so I'm obviously able to reproduce the use-after-free. Like I said, this
logic is fairly subtle. I think the problem is that there's an implicit
assumption that the fence has an external ref before someone
Dirk Thierbach writes:
>[...]
>> The stuff about overscan/etc are exposed as KMS properties (which in
>> turn appear in xrandr) and not specific to the BT869.
>
> The problem is that there's no good way to just say "I want this
> overscan" and then get a valid set of register values, because of
> Meanwhile I fiddled about with nvtv and found out that it still works
> fine. The trick is that I have to switch the X-server to the desired
> TV-Out resolution before activating the TV-Out, otherwise the X-server
> freezes.
Hm, the freeze is new. :-) You can switch X modes from the command
line
https://bugs.freedesktop.org/show_bug.cgi?id=70354
--- Comment #22 from Joey 4712 <4712.j...@gmail.com> ---
Thanks s much.
It's working now with you patch applied against Linux 3.13 Kernel source on
Manjaro Linux.
$ xrandr --setprovideroffloadsink nouveau Intel
$ DRI_PRIME=1 glxgears -in
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #39 from Ilia Mirkin ---
(In reply to comment #38)
> I wasn't clear enough in comment 34, let me explain better :-)
>
> The Mozilla change that exposed this,
> https://bugzilla.mozilla.org/show_bug.cgi?id=860254, is exactly about hav
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #38 from Benoit Jacob ---
I wasn't clear enough in comment 34, let me explain better :-)
The Mozilla change that exposed this,
https://bugzilla.mozilla.org/show_bug.cgi?id=860254, is exactly about having
memory overwritten immediatel
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #37 from Ilia Mirkin ---
(In reply to comment #36)
> Can you reproduce yourself by running the attached glxtest program in
> valgrind?
Oh, I'm sure (can't right now, will try tonight). But I doubt it's the source
of the bug. The glxt
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #36 from Benoit Jacob ---
Can you reproduce yourself by running the attached glxtest program in valgrind?
--
You are receiving this mail because:
You are the assignee for the bug.
___
Nouv
https://bugs.freedesktop.org/show_bug.cgi?id=75813
--- Comment #1 from Ilia Mirkin ---
Full dmesg would be great, esp the messages that led up to the GPU lockup. If
you have libvdpau_nouveau.so installed, try removing it, that has been reported
to cause issues on nv4x's.
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #35 from Ilia Mirkin ---
(In reply to comment #33)
> The stack to the free() points to line 203 here, while the stack to where
> the free'd data is subsequently used points to line 205 here:
>
> http://cgit.freedesktop.org/mesa/mesa/
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #34 from Benoit Jacob ---
Also, here's the story of how that caused Firefox to keep spinning here. The
mozilla change that made this bug noticeable (by having Firefox stuck for a
minute there) was https://bugzilla.mozilla.org/show_bug
On Wed, Mar 5, 2014 at 2:57 PM, Nils Krafft wrote:
> Hi,
>
> Ilia Mirkin [Mi, 05.03.2014 12:46]:
>> On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach wrote:
>> > On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
>> >> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft wrote:
>> >> > I have her
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #33 from Benoit Jacob ---
The stack to the free() points to line 203 here, while the stack to where the
free'd data is subsequently used points to line 205 here:
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #32 from Benoit Jacob ---
...note that the log attached by Frederic in comment 30 also has a stack to
where this pointer was free'd --- we have a use-after-free bug here!
This was obtained by Frederic by running the glxtest program a
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #31 from Frederic Bezies ---
Created attachment 95189
--> https://bugs.freedesktop.org/attachment.cgi?id=95189&action=edit
Valgrind log with debug symbols for Mozilla Firefox trunk code.
And log for mozilla Firefox trunk code.
Alw
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #30 from Frederic Bezies ---
Created attachment 95188
--> https://bugs.freedesktop.org/attachment.cgi?id=95188&action=edit
Valgrind log for glxtest
Here is the valgrind log for Glx test
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=75813
Priority: medium
Bug ID: 75813
Assignee: nouveau@lists.freedesktop.org
Summary: [NV40] X hangs, system unresponsive
QA Contact: xorg-t...@lists.x.org
Severity: major
Classification:
https://bugs.freedesktop.org/show_bug.cgi?id=75279
--- Comment #29 from Frederic Bezies ---
Looks like a NouVeau is triggered by Mozilla Firefox trunk code.
I opened a bug on mozilla bugtracker,
https://bugzilla.mozilla.org/show_bug.cgi?id=978439
Even if I find a "dirty workaround", valgrind lo
Hi,
Ilia Mirkin [Mi, 05.03.2014 12:46]:
> On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach wrote:
> > On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
> >> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft wrote:
> >> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
>
On Wed, Mar 05, 2014 at 12:46:04PM -0500, Ilia Mirkin wrote:
> I actually checked this out last night, grabbed the BT869 datasheet.
> Basically you'd have to implement something similar to the ch7006
> driver (see drivers/gpu/drm/i2c), which provides an API for setting
> modes (the BT869 appears to
On Wed, Mar 5, 2014 at 5:37 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> Noticed by inspection, untested. Would be interesting to see if this fixes
> anything.
I noticed that the nvc0 bit is bogus -- mt->ms_x/y aren't used to
determine ms there (it does log2(samples) directly).
On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach wrote:
> On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
>> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft wrote:
>> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
>> > TV-Out.
>
> You can try nvtv (http://sourceforg
https://bugs.freedesktop.org/show_bug.cgi?id=75203
--- Comment #10 from christian.erdm...@tu-dortmund.de ---
Created attachment 95180
--> https://bugs.freedesktop.org/attachment.cgi?id=95180&action=edit
dmesg with nouveau debug info
This debug output was created by adding
'nouveau.debug="PDISP=
https://bugs.freedesktop.org/show_bug.cgi?id=75800
christian.erdm...@tu-dortmund.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
https://bugs.freedesktop.org/show_bug.cgi?id=75203
christian.erdm...@tu-dortmund.de changed:
What|Removed |Added
CC||christian.erdmann@tu-do
https://bugs.freedesktop.org/show_bug.cgi?id=75800
Priority: medium
Bug ID: 75800
Assignee: nouveau@lists.freedesktop.org
Summary: [NVE4] [GTX660Ti] Pink line on left side of monitor
and slightly blurry areas on screen
Severi
https://bugs.freedesktop.org/show_bug.cgi?id=58556
--- Comment #22 from Pierre Moreau ---
Using commit e18833a518777e249b6badf54f65b37b741b6864
(http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=e18833a518777e249b6badf54f65b37b741b6864)
fixes the issue (tested on Git HEAD and on 3.13.5).
T
On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft wrote:
> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
> > TV-Out.
You can try nvtv (http://sourceforge.net/projects/nv-tv-out/). It bypasses
X and modesetting and p
Signed-off-by: Ilia Mirkin
---
Noticed by inspection, untested. Would be interesting to see if this fixes
anything.
src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/
Hello,
I've been tracking down a regression in fbo-generatemipmap-formats
with ARB_depth_texture on nouveau (nv50 and nvc0 are affected) since
http://cgit.freedesktop.org/mesa/mesa/commit/?id=0a1479c829ed34a65e60c6619a8164e1b079aaee
FTR, the test I'm running is:
bin/fbo-generatemipmap-formats GL
34 matches
Mail list logo
