[Nouveau] [Bug 91779] Pure EFI: MacBookPro3, 1 (NV84) fails to load nouveau on linux 4.1 -- Invalid ROM contents

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

--- Comment #11 from Jeremy Huddleston  ---
Sweet.  Thanks for the help.  So with 'sudo modprobe nouveau
config=NvBios=vbios.rom,NvForcePost=1', I'm seeing things working great so far.
 The kernel logging from the initialization is shown below.

So now that *I'm* up and running, what can we do to help out Joe User here? 
I'll try out a newer kernel to see if NvForcePost=1 is still required, and if
not, maybe we'll need a quirk.  And what can we do to get the firmware for Joe
User?

Aug 30 23:28:30 wedge kernel: [  124.139997] [drm] Initialized drm 1.1.0
20060810
Aug 30 23:28:30 wedge kernel: [  124.174617] wmi: Mapper loaded
Aug 30 23:28:30 wedge kernel: [  124.245291] checking generic (c003 71)
vs hw (c000 1000)
Aug 30 23:28:30 wedge kernel: [  124.245295] fb: conflicting fb hw usage
nouveaufb vs EFI VGA - removing generic driver
Aug 30 23:28:30 wedge kernel: [  124.245377] Console: switching to colour dummy
device 80x25
Aug 30 23:28:30 wedge kernel: [  124.245495] nouveau :01:00.0: enabling
device (0006 -> 0007)
Aug 30 23:28:30 wedge kernel: [  124.245734] [drm] hdmi device  not found 1 0 1
Aug 30 23:28:30 wedge kernel: [  124.246032] nouveau  [  DEVICE][:01:00.0]
BOOT0  : 0x084700a2
Aug 30 23:28:30 wedge kernel: [  124.246035] nouveau  [  DEVICE][:01:00.0]
Chipset: G84 (NV84)
Aug 30 23:28:30 wedge kernel: [  124.246038] nouveau  [  DEVICE][:01:00.0]
Family : NV50
Aug 30 23:28:30 wedge kernel: [  124.265240] nouveau  [   VBIOS][:01:00.0]
image: vbios.rom
Aug 30 23:28:30 wedge kernel: [  124.265323] nouveau  [   VBIOS][:01:00.0]
... appears to be valid
Aug 30 23:28:30 wedge kernel: [  124.265489] nouveau  [   VBIOS][:01:00.0]
BIT signature found
Aug 30 23:28:30 wedge kernel: [  124.265495] nouveau  [   VBIOS][:01:00.0]
version 60.84.49.03.00
Aug 30 23:28:30 wedge kernel: [  124.265707] nouveau  [   VBIOS][:01:00.0]
running init tables
Aug 30 23:28:31 wedge kernel: [  124.326633] nouveau :01:00.0: irq 48 for
MSI/MSI-X
Aug 30 23:28:31 wedge kernel: [  124.326656] nouveau  [ PMC][:01:00.0]
MSI interrupts enabled
Aug 30 23:28:31 wedge kernel: [  124.326708] nouveau  [ PFB][:01:00.0]
RAM type: GDDR3
Aug 30 23:28:31 wedge kernel: [  124.326712] nouveau  [ PFB][:01:00.0]
RAM size: 128 MiB
Aug 30 23:28:31 wedge kernel: [  124.326716] nouveau  [ PFB][:01:00.0] 
  ZCOMP: 1892 tags
Aug 30 23:28:31 wedge kernel: [  124.335737] nouveau  [VOLT][:01:00.0]
GPU voltage: 113uv
Aug 30 23:28:31 wedge kernel: [  124.359793] nouveau  [  PTHERM][:01:00.0]
FAN control: none / external
Aug 30 23:28:31 wedge kernel: [  124.359802] nouveau  [  PTHERM][:01:00.0]
fan management: automatic
Aug 30 23:28:31 wedge kernel: [  124.359806] nouveau  [  PTHERM][:01:00.0]
internal sensor: yes
Aug 30 23:28:31 wedge kernel: [  124.359832] nouveau  [ CLK][:01:00.0]
20: core 169 MHz shader 338 MHz memory 100 MHz
Aug 30 23:28:31 wedge kernel: [  124.359836] nouveau  [ CLK][:01:00.0]
21: core 283 MHz shader 566 MHz memory 297 MHz
Aug 30 23:28:31 wedge kernel: [  124.359840] nouveau  [ CLK][:01:00.0]
22: core 375 MHz shader 750 MHz memory 502 MHz
Aug 30 23:28:31 wedge kernel: [  124.359843] nouveau  [ CLK][:01:00.0]
23: core 470 MHz shader 940 MHz memory 635 MHz
Aug 30 23:28:31 wedge kernel: [  124.359883] nouveau  [ CLK][:01:00.0]
--: core 275 MHz shader 550 MHz memory 300 MHz
Aug 30 23:28:31 wedge kernel: [  124.360073] [TTM] Zone  kernel: Available
graphics memory: 2022336 kiB
Aug 30 23:28:31 wedge kernel: [  124.360075] [TTM] Initializing pool allocator
Aug 30 23:28:31 wedge kernel: [  124.360080] [TTM] Initializing DMA pool
allocator
Aug 30 23:28:31 wedge kernel: [  124.360091] nouveau  [ DRM] VRAM: 128 MiB
Aug 30 23:28:31 wedge kernel: [  124.360093] nouveau  [ DRM] GART: 1048576
MiB
Aug 30 23:28:31 wedge kernel: [  124.360098] nouveau  [ DRM] TMDS table
version 2.0
Aug 30 23:28:31 wedge kernel: [  124.360100] nouveau  [ DRM] DCB version
4.0
Aug 30 23:28:31 wedge kernel: [  124.360103] nouveau  [ DRM] DCB outp 00:
01000123 00010034
Aug 30 23:28:31 wedge kernel: [  124.360105] nouveau  [ DRM] DCB outp 01:
02011210 0028
Aug 30 23:28:31 wedge kernel: [  124.360107] nouveau  [ DRM] DCB outp 02:
02011212 00010030
Aug 30 23:28:31 wedge kernel: [  124.360110] nouveau  [ DRM] DCB outp 03:
01011211 0080c070
Aug 30 23:28:31 wedge kernel: [  124.360112] nouveau  [ DRM] DCB conn 00:
0040
Aug 30 23:28:31 wedge kernel: [  124.360115] nouveau  [ DRM] DCB conn 01:
1120
Aug 30 23:28:31 wedge kernel: [  124.376927] nouveau W[ DRM] unknown
connector type 20
Aug 30 23:28:31 wedge kernel: [  124.376965] nouveau W[ DRM] failed to
create encoder 0/1/0: -19
Aug 30 23:28:31 wedge kernel: [  124.376967] [drm] Supports vblank timestamp
caching Rev 2 (21.10.2013).
Aug 30 23:28:31 wedge kernel:

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

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


 On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher 
 wrote:
>>>
>>>
>>>
>>> 
>>>
 2) Since the glretrace does work outside of libreoffice impress, I
 think
 it may have something to do with the visual chosen by libreoffice
 impress,
 is there an easy way to find out what visual lo is choosing?
>>>
>>>
>>>
>>>
>>> No, it's not because of the visual. It seems to me that libreoffice
>>> changed the behavior of malloc and calloc.
>>
>>
>>
>>
>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>> it links normally to libc, and the same slide transition works fine
>> with an nv84 card which also has a gallium based mesa driver.
>>
>> I really believe this is due to libreoffice doing something opengl
>> related differently then glretrace, be it the visual or something else
>> back buffer related ...
>>
>
> Does libreoffice use llvm?  I have vague recollections of there being
> issues with llvm and libreoffice in the past because radeonsi uses
> llvm as well.



 FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
 falling back to the swtnl path. This should be extremely rare. But
 easy enough to build mesa with --disable-gallium-llvm to double-check
 (or what was the env var? DRAW_USE_LLVM=0 or something along those
 lines).
>>>
>>>
>>>
>>> I've tried building with --disable-gallium-llvm, this does not help,
>>> 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
>>> in which the animation will be shown, and then create another texture
>>> with the same dimensions to serve as back buffer I presume.
>>>
>>> ooimpress however does this:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
>>> target 2
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
>>> target 2
>>>
>>> Notice how it is creating 2 (back?) buffers and they are twice the size
>>> of
>>> the "sheet" area of impress to which the animation gets rendered.
>>
>>
>> bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
>> do NPOT textures... so those sizes are a bit odd. Perhaps there's some
>> logic that attempts to round-up-to-nearest-POT size, but instead
>> multiplies width by 2?
>
>
> Ok, some debugging / poking at thing further I now know where the multiply
> by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
> has templ->nr_samples = 4, and nv30_miptree_create has:
>
>switch (tmpl->nr_samples) {
>case 4:
>   mt->ms_mode = 0x4000;
>   mt->ms_x = 1;
>   mt->ms_y = 1;
>   break;
>case 2:
>   mt->ms_mode = 0x3000;
>   mt->ms_x = 1;
>   mt->ms_y = 0;
>   break;
>default:
>   mt->ms_mode = 0x;
>   mt->ms_x = 0;
>   mt->ms_y = 0;
>   break;
>}
>
> So it seems that glretrace is doing a normal rendering which works,
> where as ooimpress is doing a 4 way msaa rendering which does not work.
>
> Interestingly enough nv30_screen_get_param returns 0 for
> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
>
> And this hack:
>
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen
> *pscreen,
>  unsigned sample_count,
>  unsigned bindings)
>  {
> -   if (sample_count > 4)
> +   if (sample_count > 0)
>return false;
> if (!(0x0017 & (1 << sample_count)))
>return false;
>
> Fixes the slide animation misrendering (and sometimes crashing)
> in libreoffice impress.
>
> As said I think this is a hack, I currently do not understand things
> good enough to come up with a better fix.
>
> Hints how to further investigate this are appreciated.

Not surprising that ms gets somehow messed up.
PIPE_CAP_TEXTURE_MULTISAMPLE == ARB_texture_multisample, aka allowing
the existence of MS textures

[Nouveau] [Bug 90453] [NVE4] Desktop freezes & PDISP, PFIFO, PGRAPH and PGR errors

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

--- Comment #25 from Arthur Heymans  ---
Hi 
I also have this bug (screen freeze and mouse still usable) on a my system
using a nvidia 660ti [NVE4]:
dmesg gives
[  112.780941] nouveau E[   PFIFO][:03:00.0] SCHED_ERROR [ CTXSW_TIMEOUT ]
[  112.780947] nouveau E[   PFIFO][:03:00.0] PGRAPH engine fault on channel
8, recovering...

or 

[  294.274092] nouveau E[   PFIFO][:03:00.0] write fault at 0x000a002000
[PTE] from GR/GPC0/PROP_0 on channel 0x007f6ab000 [systemd-logind[426]]
[  294.274103] nouveau E[   PFIFO][:03:00.0] PGRAPH engine fault on channel
5, recovering...

I might be the same bug as I reported earlier
https://bugs.freedesktop.org/show_bug.cgi?id=90276

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

Re: [Nouveau] [PATCH 0/2] drm/nouveau: add support for 2560x1440@56 over HDMI

2015-08-31 Thread Hauke Mehrtens 
On 08/25/2015 07:09 AM, Ben Skeggs wrote:
> On 18 August 2015 at 04:04, Hauke Mehrtens  wrote:
>> On 08/08/2015 07:01 PM, Hauke Mehrtens wrote:
>>> These patches are adding support for outputting 2560x1440@56 over HDMI.
>>> This needs a pixel clock of 225 MHz which was not supported before.
>>>
>>> This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and
>>> one HDMI monitor running with 2560x1440@56 and one DVI monitor running
>>> with 1920x1200@60. This still needs testing on other graphics cards and
>>> with dual link DVI.
> Out of curiosity, what mode does the VBIOS select to display the
> system's boot messages?

The monitor is not activated before X comes up, I see the boot messages
only on my monitor connected via DVI.

You can find my vbios here:
https://www.hauke-m.de/files/.nouveau/vbios.rom

Hauke
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [RFC PATCH v2 5/5] HACK force fences updated on error

2015-08-31 Thread Konsta Hölttä 
Some error conditions just stop a channel and fences get stuck, so they
either need to be kicked ready in overwriting hw seq numbers (as nvgpu
does) or faked with a sw flag like this. This is just a hack as an
example of what would be needed.

Here, a channel id whose fences should be forced updated is passed
upwards with the uevent response. Normally, this is -1 to match no
channel id, but some error paths fake an update event with an explicit
channel id.

Note: if userspace has some meaningful timeouts on the fences, then they
do finish but without any notification that the channel is broken now
(how do you distinguish a too long gpu job from a stuck one?). In many
cases, a channel needs to be shut down completely when it breaks (e.g.,
mmu fault).

Signed-off-by: Konsta Hölttä 
---
 drm/nouveau/include/nvif/event.h   |  1 +
 drm/nouveau/include/nvkm/engine/fifo.h |  2 +-
 drm/nouveau/nouveau_fence.c| 13 -
 drm/nouveau/nvkm/engine/fifo/base.c|  3 ++-
 drm/nouveau/nvkm/engine/fifo/gf100.c   |  2 +-
 drm/nouveau/nvkm/engine/fifo/gk104.c   |  7 ++-
 drm/nouveau/nvkm/engine/fifo/nv04.c|  2 +-
 7 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drm/nouveau/include/nvif/event.h b/drm/nouveau/include/nvif/event.h
index d148b85..a9ff4ee 100644
--- a/drm/nouveau/include/nvif/event.h
+++ b/drm/nouveau/include/nvif/event.h
@@ -52,16 +52,17 @@ struct nvif_notify_conn_rep_v0 {
 };
 
 struct nvif_notify_uevent_req {
/* nvif_notify_req ... */
 };
 
 struct nvif_notify_uevent_rep {
/* nvif_notify_rep ... */
+   __u32 force_chid;
 };
 
 struct nvif_notify_eevent_req {
/* nvif_notify_req ... */
u32 chid;
 };
 
 struct nvif_notify_eevent_rep {
diff --git a/drm/nouveau/include/nvkm/engine/fifo.h 
b/drm/nouveau/include/nvkm/engine/fifo.h
index cbca477..946eb68 100644
--- a/drm/nouveau/include/nvkm/engine/fifo.h
+++ b/drm/nouveau/include/nvkm/engine/fifo.h
@@ -117,15 +117,15 @@ extern struct nvkm_oclass *gf100_fifo_oclass;
 extern struct nvkm_oclass *gk104_fifo_oclass;
 extern struct nvkm_oclass *gk20a_fifo_oclass;
 extern struct nvkm_oclass *gk208_fifo_oclass;
 extern struct nvkm_oclass *gm204_fifo_oclass;
 extern struct nvkm_oclass *gm20b_fifo_oclass;
 
 int  nvkm_fifo_uevent_ctor(struct nvkm_object *, void *, u32,
   struct nvkm_notify *);
-void nvkm_fifo_uevent(struct nvkm_fifo *);
+void nvkm_fifo_uevent(struct nvkm_fifo *, u32 force_chid);
 
 void nvkm_fifo_eevent(struct nvkm_fifo *, u32 chid, u32 error);
 
 void nv04_fifo_intr(struct nvkm_subdev *);
 int  nv04_fifo_context_attach(struct nvkm_object *, struct nvkm_object *);
 #endif
diff --git a/drm/nouveau/nouveau_fence.c b/drm/nouveau/nouveau_fence.c
index 38bccb0..b7d9987 100644
--- a/drm/nouveau/nouveau_fence.c
+++ b/drm/nouveau/nouveau_fence.c
@@ -123,50 +123,53 @@ nouveau_fence_context_put(struct kref *fence_ref)
 
 void
 nouveau_fence_context_free(struct nouveau_fence_chan *fctx)
 {
kref_put(>fence_ref, nouveau_fence_context_put);
 }
 
 static int
-nouveau_fence_update(struct nouveau_channel *chan, struct nouveau_fence_chan 
*fctx)
+nouveau_fence_update(struct nouveau_channel *chan,
+   struct nouveau_fence_chan *fctx, u32 force_chid)
 {
struct nouveau_fence *fence;
int drop = 0;
u32 seq = fctx->read(chan);
+   bool force = force_chid == chan->chid;
 
while (!list_empty(>pending)) {
fence = list_entry(fctx->pending.next, typeof(*fence), head);
 
-   if ((int)(seq - fence->base.seqno) < 0)
+   if ((int)(seq - fence->base.seqno) < 0 && !force)
break;
 
drop |= nouveau_fence_signal(fence);
}
 
return drop;
 }
 
 static int
 nouveau_fence_wait_uevent_handler(struct nvif_notify *notify)
 {
struct nouveau_fence_chan *fctx =
container_of(notify, typeof(*fctx), notify);
+   const struct nvif_notify_uevent_rep *rep = notify->data;
unsigned long flags;
int ret = NVIF_NOTIFY_KEEP;
 
spin_lock_irqsave(>lock, flags);
if (!list_empty(>pending)) {
struct nouveau_fence *fence;
struct nouveau_channel *chan;
 
fence = list_entry(fctx->pending.next, typeof(*fence), head);
chan = rcu_dereference_protected(fence->channel, 
lockdep_is_held(>lock));
-   if (nouveau_fence_update(fence->channel, fctx))
+   if (nouveau_fence_update(fence->channel, fctx, rep->force_chid))
ret = NVIF_NOTIFY_DROP;
}
spin_unlock_irqrestore(>lock, flags);
 
return ret;
 }
 
 void
@@ -278,17 +281,17 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct 
nouveau_channel *chan)
kref_get(>fence_ref);
 
trace_fence_emit(>base);
ret = fctx->emit(fence);
if (!ret) {
fence_get(>base);

[Nouveau] [RFC PATCH v2 2/5] don't verify route == owner in nvkm ioctl

2015-08-31 Thread Konsta Hölttä 
HACK: Some objects we need to access from userspace are first created in
kernel, and thus owned by the kernel layer. Bypass a safety mechanism
that allows to only use userspace-created objects and create new ones
(for userspace). The objects do not span across processes but are still
owned by the same client.

This will need to be fixed in some proper way. Will these objects be
managed by userspace at some point?

Signed-off-by: Konsta Hölttä 
---
 drm/nouveau/nvkm/core/ioctl.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drm/nouveau/nvkm/core/ioctl.c b/drm/nouveau/nvkm/core/ioctl.c
index 4459ff5..30164c7 100644
--- a/drm/nouveau/nvkm/core/ioctl.c
+++ b/drm/nouveau/nvkm/core/ioctl.c
@@ -474,18 +474,23 @@ nvkm_ioctl_path(struct nvkm_handle *parent, u32 type, u32 
nr, u32 *path,
nv_debug(object, "handle 0x%08x not found\n", path[nr]);
return -ENOENT;
}
nvkm_namedb_put(handle);
parent = handle;
}
 
if (owner != NVIF_IOCTL_V0_OWNER_ANY && owner != handle->route) {
-   nv_ioctl(object, "object route != owner\n");
-   return -EACCES;
+   nv_ioctl(object, "object route != owner: route = 0x%x, owner = 
0x$%x\n",
+   handle->route, owner);
+   /* return -EACCES; */
+
+   /* continue anyway - this is required for calling objects
+* created in the kernel for this client from userspace, such
+* as the channel fifo object or its gr obj. */
}
*route = handle->route;
*token = handle->token;
 
if (ret = -EINVAL, type < ARRAY_SIZE(nvkm_ioctl_v0)) {
if (nvkm_ioctl_v0[type].version == 0)
ret = nvkm_ioctl_v0[type].func(handle, data, size);
}
-- 
2.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [RFC PATCH v2 0/5] More explicit pushbuf error handling

2015-08-31 Thread Konsta Hölttä 
Hi there,

Resending these now that they've had some more polish and testing, and I heard
that Ben's vacation is over :-)

These patches work as a starting point for more explicit error mechanisms and
better robustness. At the moment, when a job hangs or faults, it seems that
nouveau doesn't quite know how to handle the situation and often results in a
hang. Some of these situations would require either completely resetting the
gpu, and/or a complex path for only recovering the broken channel.

To start, I worked on support for letting userspace know what exactly happened.
Proper recovery would come later. The "error notifier" in the first patch is a
simple shared buffer between kernel and userspace. Its error codes match
nvgpu's. Alternatively, the status could be queried with an ioctl, but that
would be considerably more heavyweight. I'd like to know if the event mechanism
is meant for these kinds of events at all (engines notify errors upwards to the
drm layer). Another alternative would probably be to register the same buffer
to all necessary engines separately in nvif method calls? Or register it to
just one (e.g., fifo) and get that engine when errors happen in others (e.g.,
gr)? And drm handles probably wouldn't fit there? Please comment on this; I
wrote this before understanding the mthd mechanism.

Additionally, priority and timeout management for separate channels in flight
on the gpu is added in two patches. Neither is exactly what the name says, but
the effect is the same, and this is what nvgpu does currently. Those two
patches call the fifo channel object's methods directly from userspace, so a
hack is added in the nvif path to accept that. The objects are NEW'd from
kernel space, so calling from userspace isn't allowed, as it appears. How
should this be managed in a clean way?

Also, since nouveau often hangs on errors, the userspace hangs too (waiting on
a fence). The final patch attempts to fix this in a couple of specific error
paths to forcibly update all fences to be finished. I'd like to hear how that
would be handled properly - consider the patch just a proof-of-concept and
sample of what would be necessary.

I don't expect the patches to be accepted as-is - as a newbie, I'd appreciate
any high-level comments on if I've understood anything, especially the event
and nvif/method mechanisms (I use the latter from userspace with a hack
constructed from the perfmon branch seen here earlier into nvidia's internal
libdrm-equivalent). The fence-forcing thing is something that is necessary with
the error notifiers (at least with our userspace that waits really long or
infinitely on fences). I'm working specifically on Tegra and don't know much
about the desktop's userspace details, so I may be biased in some areas.

I'd be happy to write sample tests on e.g. libdrm for the new methods once the
kernel patches would get to a good shape, if that's required for accepting new
features. I tested these to work as a proof-of-concept on Jetson TK1, and the
code is adapted from the latest nvgpu.

The patches can also be found in http://github.com/sooda/nouveau and are based
on a version of gnurou/staging.

Thanks!
Konsta (sooda in IRC)

Konsta Hölttä (5):
  notify channel errors to userspace
  don't verify route == owner in nvkm ioctl
  gk104: channel priority/timeslice support
  gk104: channel timeout detection
  HACK force fences updated on error

 drm/nouveau/include/nvif/class.h   |  20 
 drm/nouveau/include/nvif/event.h   |  12 +++
 drm/nouveau/include/nvkm/engine/fifo.h |   5 +-
 drm/nouveau/nouveau_chan.c |  95 +++
 drm/nouveau/nouveau_chan.h |  10 ++
 drm/nouveau/nouveau_drm.c  |   1 +
 drm/nouveau/nouveau_fence.c|  13 ++-
 drm/nouveau/nouveau_gem.c  |  29 ++
 drm/nouveau/nouveau_gem.h  |   2 +
 drm/nouveau/nvkm/core/ioctl.c  |   9 +-
 drm/nouveau/nvkm/engine/fifo/base.c|  56 ++-
 drm/nouveau/nvkm/engine/fifo/gf100.c   |   2 +-
 drm/nouveau/nvkm/engine/fifo/gk104.c   | 166 ++---
 drm/nouveau/nvkm/engine/fifo/nv04.c|   2 +-
 drm/nouveau/nvkm/engine/gr/gf100.c |   5 +
 drm/nouveau/uapi/drm/nouveau_drm.h |  13 +++
 16 files changed, 415 insertions(+), 25 deletions(-)

-- 
2.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [RFC PATCH v2 4/5] gk104: channel timeout detection

2015-08-31 Thread Konsta Hölttä 
Enable the scheduling timeout error interrupt and set it to a low value
to happen periodically, since it can be missed in HW in certain
conditions. Increment a channel-specific counter in software in the
error handler if the current channel hasn't advanced. Abort the channel
once the timeout limit is hit (with the periodic granularity). The error
notifier is set to NOUVEAU_GEM_CHANNEL_FIFO_ERROR_IDLE_TIMEOUT when this
occurs.

A new KEPLER_SET_CHANNEL_TIMEOUT mthd sets the timeout limit, in
milliseconds. The interrupt granularity is set to 100 ms.

Some status bit mangling in the sched error handler is cleaned up too.

Signed-off-by: Konsta Hölttä 
---
 drm/nouveau/include/nvif/class.h |  8 
 drm/nouveau/nvkm/engine/fifo/gk104.c | 92 +---
 2 files changed, 84 insertions(+), 16 deletions(-)

diff --git a/drm/nouveau/include/nvif/class.h b/drm/nouveau/include/nvif/class.h
index 72c3b37..9b568dc 100644
--- a/drm/nouveau/include/nvif/class.h
+++ b/drm/nouveau/include/nvif/class.h
@@ -620,18 +620,26 @@ struct fermi_a_zbc_depth_v0 {
__u8  format;
__u8  index;
__u8  pad03[5];
__u32 ds;
__u32 l2;
 };
 
 #define KEPLER_SET_CHANNEL_PRIORITY0x00
+#define KEPLER_SET_CHANNEL_TIMEOUT 0x01
+
 struct kepler_set_channel_priority_v0 {
__u8  version;
 #define KEPLER_SET_CHANNEL_PRIORITY_LOW0x00
 #define KEPLER_SET_CHANNEL_PRIORITY_MEDIUM 0x01
 #define KEPLER_SET_CHANNEL_PRIORITY_HIGH   0x02
__u8 priority;
__u8  pad03[6];
 };
 
+struct kepler_set_channel_timeout_v0 {
+   __u8  version;
+   __u8  pad03[3];
+   __u32 timeout_ms;
+};
+
 #endif
diff --git a/drm/nouveau/nvkm/engine/fifo/gk104.c 
b/drm/nouveau/nvkm/engine/fifo/gk104.c
index fda726d..53a464d 100644
--- a/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -49,16 +49,20 @@ static const struct {
_(NVDEV_ENGINE_MSVLD   , 0),
_(NVDEV_ENGINE_CE0 , 0),
_(NVDEV_ENGINE_CE1 , 0),
_(NVDEV_ENGINE_MSENC   , 0),
 };
 #undef _
 #define FIFO_ENGINE_NR ARRAY_SIZE(fifo_engine)
 
+#define CTXSW_STATUS_LOAD 5
+#define CTXSW_STATUS_SAVE 6
+#define CTXSW_STATUS_SWITCH 7
+
 struct gk104_fifo_engn {
struct nvkm_gpuobj *runlist[2];
int cur_runlist;
wait_queue_head_t wait;
 };
 
 struct gk104_fifo_priv {
struct nvkm_fifo base;
@@ -83,18 +87,25 @@ struct gk104_fifo_base {
 struct gk104_fifo_chan {
struct nvkm_fifo_chan base;
u32 engine;
enum {
STOPPED,
RUNNING,
KILLED
} state;
+   struct {
+   u32 sum_ms;
+   u32 limit_ms;
+   u32 gpfifo_get;
+   } timeout;
 };
 
+#define GRFIFO_TIMEOUT_CHECK_PERIOD_MS 100
+
 
/***
  * FIFO channel objects
  
**/
 
 static void
 gk104_fifo_runlist_update(struct gk104_fifo_priv *priv, u32 engine)
 {
struct nvkm_bar *bar = nvkm_bar(priv);
@@ -288,16 +299,21 @@ gk104_fifo_chan_ctor(struct nvkm_object *parent, struct 
nvkm_object *engine,
nv_wo32(base, 0x94, 0x3001);
nv_wo32(base, 0x9c, 0x0100);
nv_wo32(base, 0xac, 0x001f);
nv_wo32(base, 0xe8, chan->base.chid);
nv_wo32(base, 0xb8, 0xf800);
nv_wo32(base, 0xf8, 0x10003080); /* 0x002310 */
nv_wo32(base, 0xfc, 0x1010); /* 0x002350 */
bar->flush(bar);
+
+   chan->timeout.sum_ms = 0;
+   chan->timeout.limit_ms = -1;
+   chan->timeout.gpfifo_get = 0;
+
return 0;
 }
 
 static int
 gk104_fifo_chan_init(struct nvkm_object *object)
 {
struct nvkm_gpuobj *base = nv_gpuobj(object->parent);
struct gk104_fifo_priv *priv = (void *)object->engine;
@@ -381,21 +397,39 @@ gk104_fifo_chan_set_priority(struct nvkm_object *object, 
void *data, u32 size)
}
return gk104_fifo_set_runlist_timeslice(priv, chan, slice);
}
 
return ret;
 }
 
 int
+gk104_fifo_chan_set_timeout(struct nvkm_object *object, void *data, u32 size)
+{
+   struct gk104_fifo_chan *chan = (void *)object;
+   union {
+   struct kepler_set_channel_timeout_v0 v0;
+   } *args = data;
+   int ret;
+
+   if (nvif_unpack(args->v0, 0, 0, false)) {
+   chan->timeout.limit_ms = args->v0.timeout_ms;
+   }
+
+   return ret;
+}
+
+int
 gk104_fifo_chan_mthd(struct nvkm_object *object, u32 mthd, void *data, u32 
size)
 {
switch (mthd) {
case KEPLER_SET_CHANNEL_PRIORITY:
return gk104_fifo_chan_set_priority(object, data, size);
+   case

[Nouveau] [RFC PATCH v2 3/5] gk104: channel priority/timeslice support

2015-08-31 Thread Konsta Hölttä 
Change channel "priorities" by modifying the runlist timeslice value,
thus giving more time for more important jobs before scheduling a
context switch.

A new KEPLER_SET_CHANNEL_PRIORITY mthd on fifo channel objects sets the
priority to low, medium or high.

Disable the channel and preempt it out, change the timeslice, and then
enable the channel again. The shift bit in the timeslice register is
left untouched (i.e., 3) as is the enable bit.

Signed-off-by: Konsta Hölttä 
---
 drm/nouveau/include/nvif/class.h | 10 ++
 drm/nouveau/nvkm/engine/fifo/gk104.c | 60 
 2 files changed, 70 insertions(+)

diff --git a/drm/nouveau/include/nvif/class.h b/drm/nouveau/include/nvif/class.h
index 28176e6..72c3b37 100644
--- a/drm/nouveau/include/nvif/class.h
+++ b/drm/nouveau/include/nvif/class.h
@@ -619,9 +619,19 @@ struct fermi_a_zbc_depth_v0 {
 #define FERMI_A_ZBC_DEPTH_V0_FMT_FP32  0x01
__u8  format;
__u8  index;
__u8  pad03[5];
__u32 ds;
__u32 l2;
 };
 
+#define KEPLER_SET_CHANNEL_PRIORITY0x00
+struct kepler_set_channel_priority_v0 {
+   __u8  version;
+#define KEPLER_SET_CHANNEL_PRIORITY_LOW0x00
+#define KEPLER_SET_CHANNEL_PRIORITY_MEDIUM 0x01
+#define KEPLER_SET_CHANNEL_PRIORITY_HIGH   0x02
+   __u8 priority;
+   __u8  pad03[6];
+};
+
 #endif
diff --git a/drm/nouveau/nvkm/engine/fifo/gk104.c 
b/drm/nouveau/nvkm/engine/fifo/gk104.c
index 659c05f..fda726d 100644
--- a/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -333,22 +333,82 @@ gk104_fifo_chan_fini(struct nvkm_object *object, bool 
suspend)
gk104_fifo_runlist_update(priv, chan->engine);
}
 
gk104_fifo_chan_kick(chan);
nv_wr32(priv, 0x80 + (chid * 8), 0x);
return nvkm_fifo_channel_fini(>base, suspend);
 }
 
+static int
+gk104_fifo_set_runlist_timeslice(struct gk104_fifo_priv *priv,
+   struct gk104_fifo_chan *chan, u8 slice)
+{
+   struct nvkm_gpuobj *base = nv_gpuobj(nv_object(chan)->parent);
+   u32 chid = chan->base.chid;
+
+   nv_mask(priv, 0x84 + (chid * 8), 0x0800, 0x0800);
+   WARN_ON(gk104_fifo_chan_kick(chan));
+   nv_wo32(base, 0xf8, slice | 0x10003000);
+   nv_mask(priv, 0x84 + (chid * 8), 0x0400, 0x0400);
+   nv_info(chan, "timeslice set to %d for %d\n", slice, chid);
+
+   return 0;
+}
+
+int
+gk104_fifo_chan_set_priority(struct nvkm_object *object, void *data, u32 size)
+{
+   struct gk104_fifo_priv *priv = (void *)object->engine;
+   struct gk104_fifo_chan *chan = (void *)object;
+   union {
+   struct kepler_set_channel_priority_v0 v0;
+   } *args = data;
+   int ret;
+   u8 slice;
+
+   if (nvif_unpack(args->v0, 0, 0, false)) {
+   switch (args->v0.priority) {
+   case KEPLER_SET_CHANNEL_PRIORITY_LOW:
+   slice = 64; /* << 3 == 512 us */
+   break;
+   case KEPLER_SET_CHANNEL_PRIORITY_MEDIUM:
+   slice = 128; /* 1 ms */
+   break;
+   case KEPLER_SET_CHANNEL_PRIORITY_HIGH:
+   slice = 255; /* 2 ms */
+   break;
+   default:
+   return -EINVAL;
+   }
+   return gk104_fifo_set_runlist_timeslice(priv, chan, slice);
+   }
+
+   return ret;
+}
+
+int
+gk104_fifo_chan_mthd(struct nvkm_object *object, u32 mthd, void *data, u32 
size)
+{
+   switch (mthd) {
+   case KEPLER_SET_CHANNEL_PRIORITY:
+   return gk104_fifo_chan_set_priority(object, data, size);
+   default:
+   break;
+   }
+   return -EINVAL;
+}
+
 struct nvkm_ofuncs
 gk104_fifo_chan_ofuncs = {
.ctor = gk104_fifo_chan_ctor,
.dtor = _nvkm_fifo_channel_dtor,
.init = gk104_fifo_chan_init,
.fini = gk104_fifo_chan_fini,
+   .mthd = gk104_fifo_chan_mthd,
.map  = _nvkm_fifo_channel_map,
.rd32 = _nvkm_fifo_channel_rd32,
.wr32 = _nvkm_fifo_channel_wr32,
.ntfy = _nvkm_fifo_channel_ntfy
 };
 
 static struct nvkm_oclass
 gk104_fifo_sclass[] = {
-- 
2.1.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [RFC PATCH v2 1/5] notify channel errors to userspace

2015-08-31 Thread Konsta Hölttä 
Let userspace know about some specific types of errors via a shared
buffer registered with a new ioctl, NOUVEAU_GEM_SET_ERROR_NOTIFIER.
Once set, the notifier buffer is used until the channel is destroyed.
The exceptional per-channel error conditions are signaled upwards from
the nvkm layer via the event/notify mechanism and written to the buffer
which holds the latest error occurred, readable from userspace.

Some error situations render a channel completely stuck, which may
require even discarding and reinitializing it or the gpu completely.
Once a specific type of error happens, no others are expected until
recovery. Passing the error to userspace in a shared buffer enables the
graphics driver to periodically check in a light-weight way if anything
went wrong (typically, after a submit); e.g., the GL robustness
extension requires to detect that the context has dead.

The notifier currently signals idle timeout, sw notify, mmu fault and
illegal pbdma error conditions.

Signed-off-by: Konsta Hölttä 
---
 drm/nouveau/include/nvif/class.h   |  2 +
 drm/nouveau/include/nvif/event.h   | 11 
 drm/nouveau/include/nvkm/engine/fifo.h |  3 ++
 drm/nouveau/nouveau_chan.c | 95 ++
 drm/nouveau/nouveau_chan.h | 10 
 drm/nouveau/nouveau_drm.c  |  1 +
 drm/nouveau/nouveau_gem.c  | 29 +++
 drm/nouveau/nouveau_gem.h  |  2 +
 drm/nouveau/nvkm/engine/fifo/base.c| 53 +++
 drm/nouveau/nvkm/engine/fifo/gk104.c   | 13 +
 drm/nouveau/nvkm/engine/gr/gf100.c |  5 ++
 drm/nouveau/uapi/drm/nouveau_drm.h | 13 +
 12 files changed, 237 insertions(+)

diff --git a/drm/nouveau/include/nvif/class.h b/drm/nouveau/include/nvif/class.h
index d90e207..28176e6 100644
--- a/drm/nouveau/include/nvif/class.h
+++ b/drm/nouveau/include/nvif/class.h
@@ -410,16 +410,18 @@ struct kepler_channel_gpfifo_a_v0 {
__u8  engine;
__u16 chid;
__u8  pad04[4];
__u32 pushbuf;
__u32 ilength;
__u64 ioffset;
 };
 
+#define CHANNEL_GPFIFO_ERROR_NOTIFIER_EEVENT   0x01
+
 
/***
  * legacy display
  
**/
 
 #define NV04_DISP_NTFY_VBLANK  0x00
 #define NV04_DISP_NTFY_CONN0x01
 
 struct nv04_disp_mthd_v0 {
diff --git a/drm/nouveau/include/nvif/event.h b/drm/nouveau/include/nvif/event.h
index 2176449..d148b85 100644
--- a/drm/nouveau/include/nvif/event.h
+++ b/drm/nouveau/include/nvif/event.h
@@ -54,9 +54,20 @@ struct nvif_notify_conn_rep_v0 {
 struct nvif_notify_uevent_req {
/* nvif_notify_req ... */
 };
 
 struct nvif_notify_uevent_rep {
/* nvif_notify_rep ... */
 };
 
+struct nvif_notify_eevent_req {
+   /* nvif_notify_req ... */
+   u32 chid;
+};
+
+struct nvif_notify_eevent_rep {
+   /* nvif_notify_rep ... */
+   u32 error;
+   u32 chid;
+};
+
 #endif
diff --git a/drm/nouveau/include/nvkm/engine/fifo.h 
b/drm/nouveau/include/nvkm/engine/fifo.h
index 9100b80..cbca477 100644
--- a/drm/nouveau/include/nvkm/engine/fifo.h
+++ b/drm/nouveau/include/nvkm/engine/fifo.h
@@ -67,16 +67,17 @@ struct nvkm_fifo_base {
 #include 
 #include 
 
 struct nvkm_fifo {
struct nvkm_engine base;
 
struct nvkm_event cevent; /* channel creation event */
struct nvkm_event uevent; /* async user trigger */
+   struct nvkm_event eevent; /* error notifier */
 
struct nvkm_object **channel;
spinlock_t lock;
u16 min;
u16 max;
 
int  (*chid)(struct nvkm_fifo *, struct nvkm_object *);
void (*pause)(struct nvkm_fifo *, unsigned long *);
@@ -118,11 +119,13 @@ extern struct nvkm_oclass *gk20a_fifo_oclass;
 extern struct nvkm_oclass *gk208_fifo_oclass;
 extern struct nvkm_oclass *gm204_fifo_oclass;
 extern struct nvkm_oclass *gm20b_fifo_oclass;
 
 int  nvkm_fifo_uevent_ctor(struct nvkm_object *, void *, u32,
   struct nvkm_notify *);
 void nvkm_fifo_uevent(struct nvkm_fifo *);
 
+void nvkm_fifo_eevent(struct nvkm_fifo *, u32 chid, u32 error);
+
 void nv04_fifo_intr(struct nvkm_subdev *);
 int  nv04_fifo_context_attach(struct nvkm_object *, struct nvkm_object *);
 #endif
diff --git a/drm/nouveau/nouveau_chan.c b/drm/nouveau/nouveau_chan.c
index 0589bab..ff37f5f 100644
--- a/drm/nouveau/nouveau_chan.c
+++ b/drm/nouveau/nouveau_chan.c
@@ -19,26 +19,29 @@
  * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  * Authors: Ben Skeggs
  */
 
 #include 
 #include 
+#include 
+#include 
 
 /*XXX*/
 #include 
 
 #include "nouveau_drm.h"
 #include "nouveau_dma.h"
 #include "nouveau_bo.h"
 #include "nouveau_chan.h"
 #include "nouveau_fence.h"

[Nouveau] [PATCH] gr/nv04: fix big endian setting on gr context

2015-08-31 Thread Ilia Mirkin 
Broken since "gr: convert user classes to new-style nvkm_object"

Tested on a PPC64 G5 + NV34

Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nvkm/engine/gr/nv04.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nvkm/engine/gr/nv04.c 
b/drm/nouveau/nvkm/engine/gr/nv04.c
index 426ba00..85c5b7f 100644
--- a/drm/nouveau/nvkm/engine/gr/nv04.c
+++ b/drm/nouveau/nvkm/engine/gr/nv04.c
@@ -1048,11 +1048,11 @@ nv04_gr_object_bind(struct nvkm_object *object, struct 
nvkm_gpuobj *parent,
if (ret == 0) {
nvkm_kmap(*pgpuobj);
nvkm_wo32(*pgpuobj, 0x00, object->oclass);
-   nvkm_wo32(*pgpuobj, 0x04, 0x);
-   nvkm_wo32(*pgpuobj, 0x08, 0x);
 #ifdef __BIG_ENDIAN
-   nvkm_mo32(*pgpuobj, 0x08, 0x0008, 0x0008);
+   nvkm_mo32(*pgpuobj, 0x00, 0x0008, 0x0008);
 #endif
+   nvkm_wo32(*pgpuobj, 0x04, 0x);
+   nvkm_wo32(*pgpuobj, 0x08, 0x);
nvkm_wo32(*pgpuobj, 0x0c, 0x);
nvkm_done(*pgpuobj);
}
-- 
2.4.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

2015-08-31 Thread Hans de Goede 

Hi,

On 28-08-15 11:02, Ilia Mirkin wrote:

On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede  wrote:

Hi,

On 27-08-15 20:19, Ilia Mirkin wrote:


On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher 
wrote:






2) Since the glretrace does work outside of libreoffice impress, I
think
it may have something to do with the visual chosen by libreoffice
impress,
is there an easy way to find out what visual lo is choosing?




No, it's not because of the visual. It seems to me that libreoffice
changed the behavior of malloc and calloc.




I'm pretty sure that this is not libreoffice changing malloc / calloc,
it links normally to libc, and the same slide transition works fine
with an nv84 card which also has a gallium based mesa driver.

I really believe this is due to libreoffice doing something opengl
related differently then glretrace, be it the visual or something else
back buffer related ...



Does libreoffice use llvm?  I have vague recollections of there being
issues with llvm and libreoffice in the past because radeonsi uses
llvm as well.



FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
falling back to the swtnl path. This should be extremely rare. But
easy enough to build mesa with --disable-gallium-llvm to double-check
(or what was the env var? DRAW_USE_LLVM=0 or something along those
lines).



I've tried building with --disable-gallium-llvm, this does not help,
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
in which the animation will be shown, and then create another texture
with the same dimensions to serve as back buffer I presume.

ooimpress however does this:

nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
target 2
nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
target 2

Notice how it is creating 2 (back?) buffers and they are twice the size of
the "sheet" area of impress to which the animation gets rendered.


bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
do NPOT textures... so those sizes are a bit odd. Perhaps there's some
logic that attempts to round-up-to-nearest-POT size, but instead
multiplies width by 2?


Ok, some debugging / poking at thing further I now know where the multiply
by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
has templ->nr_samples = 4, and nv30_miptree_create has:

   switch (tmpl->nr_samples) {
   case 4:
  mt->ms_mode = 0x4000;
  mt->ms_x = 1;
  mt->ms_y = 1;
  break;
   case 2:
  mt->ms_mode = 0x3000;
  mt->ms_x = 1;
  mt->ms_y = 0;
  break;
   default:
  mt->ms_mode = 0x;
  mt->ms_x = 0;
  mt->ms_y = 0;
  break;
   }

So it seems that glretrace is doing a normal rendering which works,
where as ooimpress is doing a 4 way msaa rendering which does not work.

Interestingly enough nv30_screen_get_param returns 0 for
PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET

And this hack:

--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen,
 unsigned sample_count,
 unsigned bindings)
 {
-   if (sample_count > 4)
+   if (sample_count > 0)
   return false;
if (!(0x0017 & (1 << sample_count)))
   return false;

Fixes the slide animation misrendering (and sometimes crashing)
in libreoffice impress.

As said I think this is a hack, I currently do not understand things
good enough to come up with a better fix.

Hints how to further investigate this are appreciated.

Regards,

Hans
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau