Re: [Nouveau] nouveau: iowrite32 oops & warning at drivers/gpu/drm/nouveau/nouveau_fence.c:198

Hi Tommi, Not sure if these apply here but there are a couple of outstanding locking fixes available in http://cgit.freedesktop.org/~darktama/nouveau/ -- specifically these two: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=2f3a56ad019e378a352e9cb7a559f478826f1a87

Re: [Nouveau] [PATCH v2] pmu: fix queued messages while getting no IRQ

On Sat, Nov 14, 2015 at 1:44 PM, Karol Herbst wrote: > I encountered while stresstesting the reclocking code, that rarely (1 out of > 20.000+ requests) we don't get any IRQ in nvkm_pmu_intr. > > This means we have a queued message on the pmu, but nouveau doesn't read it >

Re: [Nouveau] llvm TGSI backend (WIP) questions

On Fri, Nov 13, 2015 at 3:42 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 13 November 2015 at 14:38, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> H

Re: [Nouveau] llvm TGSI backend (WIP) questions

On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov wrote: > Hello Hans, > > Not to muddy the waters or anything, have you thought about the NIR > integration that Rob was thinking about ? > I'm pretty sure he'll be happy to have extra people helping him out. How would that

Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v2)

> works very similarly) create a new helper to arm vblank events for > such drivers. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 > Cc: Thierry Reding <tred...@nvidia.com> > Cc: Mario Kleiner <mario.kleiner...@gmail.com> > Cc: Ben Skeggs <bske...@

Re: [Nouveau] [PATCH mesa 0/5] nouveau: codegen: Make use of double immediates

Hi Hans, All pushed. I made a few additional fixes and improvement to fp64 immediate handling along the way, but all your commits were fine as-is. (Except that they enabled fp64 immediates on nv50 implicitly which is wrong -- there are no immediate-taking variants on nv50, so I fixed that glitch.

Re: [Nouveau] Documentation request for MP warp error 0x10

On Fri, Nov 6, 2015 at 4:19 PM, Robert Morell <rmor...@nvidia.com> wrote: > On Fri, Nov 06, 2015 at 04:15:29PM -0500, Ilia Mirkin wrote: >> In order for ATOM.*/RED.* to work, the addresses in question must >> *NOT* be inside of the 16MB local/shared windows. So if I'm

Re: [Nouveau] Documentation request for MP warp error 0x10

On Fri, Nov 6, 2015 at 3:59 PM, Robert Morell <rmor...@nvidia.com> wrote: > On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote: >> Could you advise what the proper way of indicating >> that the memory is "global" to the op? I'm sure I'm just missing >

[Nouveau] [PATCH] nvkm: add/remove 0's to make 7 (or 9)-nibble constants use 8 nibbles

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 2 +- drm/nouveau/nvkm/subdev/fb/ramgk104.c | 8 drm/nouveau/nvkm/subdev/therm/nv40.c | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drm/nouveau/nvkm/eng

Re: [Nouveau] HDMI pixel clock limits

://bugs.freedesktop.org/show_bug.cgi?id=91236 Having an accurate way to auto-detect this would be ideal though, as higher bandwidth monitors are becoming more ubiquitous. -ilia On Mon, Oct 26, 2015 at 1:35 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > Hello, > > Various HDMI versions enable hi

Re: [Nouveau] Nouveau for FreeBSD

On Wed, Nov 4, 2015 at 3:38 AM, C Bergström wrote: > To bring this conversation back on track - where would someone start > *exactly* to port this to another OS? What kernel dependencies are > there? drivers/gpu/drm/nouveau/{nvkm,nvif,usif} can be dropped in wholesale

[Nouveau] [PATCH 1/2] disp: activate dual link TMDS links only when possible

e when it is actual possible. Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nv50_display.c | 8 drm/nouveau/nvkm/engine/disp/gf119.c | 2 +- drm/nouveau/nvkm/engine/disp/nv50.c | 2 +- 3 files changed,

[Nouveau] [PATCH 2/2] connector: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter which allows end-users to set it themselves until we have a reliable way to determine the board's maximum pixel clocks. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nouveau_connector.

Re: [Nouveau] [PATCH 1/2] disp: activate dual link TMDS links only when possible

On Tue, Nov 3, 2015 at 7:02 PM, Ben Skeggs <skeg...@gmail.com> wrote: > On 11/04/2015 08:41 AM, Ilia Mirkin wrote: >> From: Hauke Mehrtens <ha...@hauke-m.de> >> >> Without this patch a pixel clock rate above 165 MHz on a TMDS link is >> assume

[Nouveau] [PATCH] kms: no need to check for empty edid before drm_detect_hdmi_monitor

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nv50_display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c index bdaba91..d9cba87 100644 --- a/drm/nouveau/nv50_display.c +++ b/drm/nouveau/nv50_display.c @@

[Nouveau] [PATCH v2 1/2] disp: activate dual link TMDS links only when possible

e when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de> [imirkin: check for hdmi monitor for computing proto, use sor ctrl to enable extra config bit] Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nv50_display.c | 18 +

[Nouveau] [PATCH v2 2/2] connector: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter which allows end-users to set it themselves until we have a reliable way to determine the board's maximum pixel clocks. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nouveau_connector.

[Nouveau] [PATCH v3 2/2] connector: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter which allows end-users to set it themselves until we have a reliable way to determine the board's maximum pixel clocks. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nouveau_connector.

[Nouveau] [PATCH v3 1/2] disp: activate dual link TMDS links only when possible

e when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de> [imirkin: check for hdmi monitor for computing proto, use sor ctrl to enable extra config bit] Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nv50_display.c | 15 ++

Re: [Nouveau] Nouveau for FreeBSD

Nouveau kernel module has a largely os-agnostic "core" component (called nvkm/nvif now) which encompasses the actual operation of the GPU. The drm wrapper around it provides the relevant interfaces for KMS/ioctls/etc. Any port would want the ioctl bits as well, since that's what the userspace

Re: [Nouveau] help with push

See libdrm's pushbuf.c -- iirc push->cur points to a GART-mapped bo. http://cgit.freedesktop.org/mesa/drm/tree/nouveau/pushbuf.c#n682 nouveau_pushbuf_data(push, NULL, 0, 0); nouveau_bo_ref(bo, >bo); nouveau_bo_ref(NULL, ); nvpb->bgn = nvpb->bo->map; nvpb->ptr = nvpb->bgn; push->cur = nvpb->bgn;

Re: [Nouveau] help with push

usion and thanks for the reply. > Awaiting > for an answer if possible. Thanks in advance. > > 2015-11-02 14:44 GMT-03:00 Ilia Mirkin <imir...@alum.mit.edu>: >> >> See libdrm's pushbuf.c -- iirc push->cur points to a GART-mapped bo. >> >> http://cgit.freede

[Nouveau] [PATCH] pci: enable c800 magic for Medion Erazer X7827

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/device/pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/engine/device/pci.c b/drm/nouveau/nvkm/engine/device/pci.c index e

[Nouveau] [PATCH] pci: enable c800 magic for Lenovo Y510P

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Unclear if we want this. Someone with the same vendor/subvendor pci ids didn't have any issues with nouveau at all: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1

Re: [Nouveau] Documentation request for MP warp error 0x10

On Fri, Oct 2, 2015 at 6:14 PM, Robert Morell <rmor...@nvidia.com> wrote: > Hi Ilia, > > On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote: >> Hi Robert, >> >> Thanks for the quick response! That goes in line with my observations >> which is that

[Nouveau] [PATCH] nvc0: respect edgeflag attribute width

). Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/nvc0/nvc0_vbo_translate.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo_translate.c b/src/gallium/d

[Nouveau] [PATCH] nvc0: do upload-time fixups for interpolation parameters

the remaining failing glsl-1.30/execution/interpolation piglits. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Incomplete as per above. Wanted to get it out there in case there was any feedback. This will only work on GK110/GK208 as-is. .../drivers/nouveau/codegen/nv50_ir_driver.h

[Nouveau] [PATCH] gem: return only valid domain when there's only one

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nouveau_gem.c | 5 +++-- lib/include/nvif/os.h | 6 ++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nouveau_gem.c b/drm/n

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

; > See my comment below. > > > On 10/10/2015 11:09 AM, Ilia Mirkin wrote: >> >> We still have to push everything out, might as well kick earlier and >> flip pushbufs when we know we'll need it. This resolves some issues with >> the new policy of making sure that we alway

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: > > > On 10/10/2015 09:42 PM, Ilia Mirkin wrote: >> >> On Sat, Oct 10, 2015 at 3:41 PM, Samuel Pitoiset >> <samuel.pitoi...@gmail.com> wrote: >>> >>>

Re: [Nouveau] [Mesa-dev] [PATCH] nouveau: avoid emitting new fences unnecessarily

: Samuel Pitoiset <samuel.pitoi...@gmail.com> > > > On 10/10/2015 08:12 AM, Ilia Mirkin wrote: >> >> Right now we emit on every kick, but this is only necessary if something >> will ever be able to observe that the fence completed. If there are no >> refs, leave th

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

On Sat, Oct 10, 2015 at 4:21 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: > > > On 10/10/2015 09:58 PM, Ilia Mirkin wrote: >> >> On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset >> <samuel.pitoi...@gmail.com> wrote: >>> >>> >&g

[Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

We still have to push everything out, might as well kick earlier and flip pushbufs when we know we'll need it. This resolves some issues with the new policy of making sure that we always leave a bit of room at the end for fences. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: me

[Nouveau] [PATCH] nouveau: avoid emitting new fences unnecessarily

after. With the new mechanism, hopefully there's no way to cause two fences to be emitted into the same reserved space. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: mesa-sta...@lists.freedesktop.org Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence) --- src/g

Re: [Nouveau] 4K ~ 3840x2160 resolution and frame buffer support

e to write frame buffer apps that run in the console. > > Thank you. > > > > On 10/08/2015 04:44 PM, Ilia Mirkin wrote: >> >> If you only get 1920x1080 in X, chances are that nouveau doesn't >> believe it can do 3840x2160 for one reason or another. There are a

Re: [Nouveau] 4K ~ 3840x2160 resolution and frame buffer support

If you only get 1920x1080 in X, chances are that nouveau doesn't believe it can do 3840x2160 for one reason or another. There are a number of reasons why this might be the case, please provide dmesg, xorg log, and information on how the monitor is connected (including any A->B type adapters).

[Nouveau] [PATCH 1/2] gr: document mp error 0x10

NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/gf100.c | 1 +

[Nouveau] [PATCH 2/2] gr: add FERMI_COMPUTE_B class to GF110+

GF110+ supports both the A and B compute classes, make sure to accept both. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/gf110.c | 1 + drm/nouveau/nvkm/engine/gr/gf117.c | 1 + drm/nouveau/nvkm/engine/gr/gf119.c | 1 + 3 files changed, 3 insertions(+)

[Nouveau] [PATCH] nouveau: make sure there's always room to emit a fence

the space checking as well. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/nouveau_winsys.h | 2 ++ src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/g

Re: [Nouveau] [PATCH] bios: fix OF loading

On Fri, Oct 2, 2015 at 3:39 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 02-10-15 09:38, Ilia Mirkin wrote: >> >> On Fri, Oct 2, 2015 at 3:35 AM, Hans de Goede <hdego...@redhat.com> wrote: >>> >>> Hi, >>> >>>

Re: [Nouveau] Documentation request for MP warp error 0x10

gt; [1] What is documented as RED internally appears to be called SUREDP in Mesa. > > > - Robert > > On Wed, Sep 30, 2015 at 03:14:47PM -0400, Ilia Mirkin wrote: >> Hello, >> >> I've recently come across an error reported by the GPU and would like >> to know wh

Re: [Nouveau] [PATCH] bios: fix OF loading

On Fri, Oct 2, 2015 at 3:18 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 02-10-15 05:41, Ilia Mirkin wrote: > > > > As someone who has recently started following nouveau I must say that > it would greatly help me (and likely others) if p

Re: [Nouveau] [PATCH] bios: fix OF loading

On Fri, Oct 2, 2015 at 3:35 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 02-10-15 09:26, Ilia Mirkin wrote: >> >> On Fri, Oct 2, 2015 at 3:18 AM, Hans de Goede <hdego...@redhat.com> wrote: >>> >>> Hi, >>> >>> On 0

[Nouveau] [PATCH] bios: fix OF loading

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Tested on a PowerMac7,3 with a NV34 AGP adapter. drm/nouveau/nvkm/subdev/bios/priv.h | 3 +++ drm/nouveau/nvkm/subdev/bios/shadow.c | 27 ++- drm/nouveau/nvkm/subdev/bios/shadowof.c | 18 +++

[Nouveau] Documentation request for MP warp error 0x10

Hello, I've recently come across an error reported by the GPU and would like to know what it means and especially what causes it to be triggered. Any information would be very useful: I'm seeing MP warp error 0x10 (appears in MP register 0x48). This is what we currently have in nouveau:

Re: [Nouveau] pstate for NVS140

On Tue, Sep 15, 2015 at 1:39 AM, Dylan Taft wrote: > I'm trying out the 4.3 RC kernel, major improvements with Nouveau on > my old T61 laptop with an NVS140 GPU. Stability and performance both > seem massively increased. There are still some stability issues with > 3D

Re: [Nouveau] [PATCH] display: allow up to 16k width/height for fermi+

On Fri, Sep 18, 2015 at 9:41 AM, Ben Skeggs <skeg...@gmail.com> wrote: > On 18 September 2015 at 12:31, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> >> --- >> >> mrnuke on IRC reported that 3x 4K

[Nouveau] [PATCH v2] nv50, nvc0: detect underlying resource changes and update tic

When updating texture buffers, we might end up replacing the whole buffer. Check that the tic address matches the resource address, and if not, update the tic and reupload it. This fixes: arb_direct_state_access-texture-buffer arb_texture_buffer_object-data-sync Signed-off-by: Ilia Mirkin

[Nouveau] [PATCH] display: allow up to 16k width/height for fermi+

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- mrnuke on IRC reported that 3x 4K monitors (11520 width total) got rejected for some reason. I'm guessing it's this since a single giant FB has to be used. Not sure if the hardware will actually support it, but... who knows. drm/n

[Nouveau] [PATCH v2] nv50, nvc0: detect underlying resource changes and update tic

When updating texture buffers, we might end up replacing the whole buffer. Check that the tic address matches the resource address, and if not, update the tic and reupload it. This fixes: arb_direct_state_access-texture-buffer arb_texture_buffer_object-data-sync Signed-off-by: Ilia Mirkin

Re: [Nouveau] [PATCH v2] pci: Handle 5-bit and 8-bit tag field

On Wed, Sep 16, 2015 at 3:52 PM, Pierre Moreau wrote: > 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

[Nouveau] [PATCH] nv50, nvc0: flush texture cache in presence of coherent bufs

This fixes the newly-added arb_texture_buffer_object-bufferstorage piglit test. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: "11.0" <mesa-sta...@lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 19 +++ src/gallium/drivers/n

Re: [Nouveau] External monitor remains black - nouveau reports "link training failed"

On Wed, Sep 16, 2015 at 1:14 PM, Fredy Neeser wrote: > > Hello list, > > I had a working dual-monitor setup with KDE Plasma 5 on a Lenovo W530 > "Optimus" laptop (hybrid graphics, nouveau + i915 drivers), but it seems to > fall apart with recent kernels, i.e., the external

[Nouveau] [PATCH] nv50, nvc0: fix max texture buffer size to 128M elements

This is what the hardware supports, there never was any sort of 64K limit. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: "10.6 11.0" <mesa-sta...@lists.freedesktop.org> --- Need to double-check this one on nv50, but online sources suggest that it's a 128M eleme

[Nouveau] [PATCH] nv50, nvc0: unlock tic and update address when invalidating resource

. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: "11.0" <mesa-sta...@lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 6 ++ src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 6 ++ 2 files changed, 12 insertions(+) diff --git a/src/g

Re: [Nouveau] AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary wrote: > Hello, > I have a PC Chips A31G board with AGPro slot and found that nouveau does not > work properly with it. Console works but reverts to software mode, X11 hangs > with mouse cursor only. > > The slot is

Re: [Nouveau] AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

On Sun, Sep 13, 2015 at 6:01 PM, Ondrej Zary <li...@rainbow-software.org> wrote: > On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote: >> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary <li...@rainbow-software.org> >> wrote: >> > Hello, >> > I have a

[Nouveau] [PATCH] nvc0: keep track of cb bindings per buffer, use for upload settings

-rendering offset' as well as blurriness in Witcher2. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91890 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: "11.0" <mesa-sta...@lists.freedesktop.org> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +- src/g

Re: [Nouveau] [PATCH mesa v2 1/2] nv30: Fix color resolving for nv3x cards

On Wed, Sep 9, 2015 at 9:52 AM, Hans de Goede wrote: > 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

Re: [Nouveau] [PATCH mesa v2 2/2] nv30: Disable msaa unless requested from the env by NV30_MAX_MSAA

On Wed, Sep 9, 2015 at 9:52 AM, Hans de Goede wrote: > Some modern apps try to use msaa without keeping in mind the > restrictions on videomem of older cards. Resulting in dmesg saying: > > [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate > [ 1197.850648]

Re: [Nouveau] [PATCH] nvc0: keep track of cb bindings per buffer, use for upload settings

On Wed, Sep 9, 2015 at 3:17 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > CB updates to bound buffers need to go through the CB_DATA endpoints, > otherwise the shader may not notice that the updates happened. > Furthermore, these updates have to go in to the same address as the

Re: [Nouveau] [PATCH mesa 3/3] nv30: Disable msaa for now because it causes lockups

On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede wrote: > msaa use on nv30 may trigger a (mesa?) bug where dmesg says: > [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate > [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list > [ 1197.850654] nouveau

Re: [Nouveau] [PATCH mesa 1/3] nv30: Fix max width / height checks in nv30 sifm code

Yeah, I noticed this was odd too when looking over the code earlier. Glad you picked up on that as well. Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: "10.6 11.0" <mesa-sta...@lists.freedesktop.org> On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdego...@redh

[Nouveau] [PATCH] nvc0: always emit a full shader colormask

piglit: fbo-stencil blit GL_DEPTH32F_STENCIL8 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Needs a piglit run on both fermi and kepler just to make sure. src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/g

Re: [Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

Tmds is limited to 135mhz on nv3x. If you use analog, you can get full resolution. On Sep 4, 2015 9:00 AM, "Hans de Goede" wrote: > Hi All, > > I've recently acquired a nvs280 card, which is a nv34 > gpu based card with a pci-e bridge on the card, this > way I can test nv3x

Re: [Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

On Fri, Sep 4, 2015 at 9:10 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 03-09-15 19:32, Ilia Mirkin wrote: >> >> On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdego...@redhat.com> wrote: >>> >>> On nv3x we will likely end

Re: [Nouveau] [PATCH mesa 4/4] nv30: Disable msaa on nv4x because it causes gpu lockups

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote: > On nv4x with a msaa visual after a while the gpu locks up, attach gdb to > impress shows it is hanging waiting for a fence which never comes. > > Killing ooimpress at this point works exactly once, trying to do any > 3d

Re: [Nouveau] [PATCH mesa 1/4] nv30: Fix creation of scanout buffers

8 | fmt->card_fmt); without OR'ing in the log2(w/h). So this looks good. I wondered how it worked at all with swizzling. I guess it didn't :) Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: "10.6 11.0" <mesa-sta...@lists.freedesktop.org> [by the way, having a git branch

Re: [Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede 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

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

On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 02-09-15 16:44, Ilia Mirkin wrote: >> >> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdego...@redhat.com> wrote: >>> >>> Hi Ilia > > > > >

Re: [Nouveau] [PATCH mesa 0/4] nv30: Various fixes

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote: > Hi All, > > Here is a bunch of fixes for nv30 cards, the first patch is a resend of > a patch I send a while back. AFAICT that one is ready for merging, but > it is not entirely clear to me what the process is for getting

Re: [Nouveau] [PATCH mesa 2/4] nv30: Implement color resolve for msaa

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdego...@redhat.com> wrote: > Note this is not ideal. Since the sifm can only do source sizes upto > 1024x1024 we end up using the blitter on nv4x, which is not that fast. Moral of the story: don't do use nv3x/nv4x :) Reviewed-by: Ilia

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

On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdego...@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 <hdego...@redhat.com> >> wrote: > > > > > &g

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

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdego...@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 <hdego...@redhat.com> >> wrote: >>> >>> Hi, >>> &g

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

Broken since "gr: convert user classes to new-style nvkm_object" Tested on a PPC64 G5 + NV34 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/nv04.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drm/nouveau/nvkm/engine/

[Nouveau] Loading vbios on OF

Hey Ben, So with the following totally-hack-patch below, I get OF to load (but I have to force it, checksum fails). Of note is the following: -r--r--r-- 1 root root 2403 Aug 28 09:31 /proc/device-tree/pci@0,f000/NVDA,Parent@10/NVDA,BMP I'm not sure why you require the vbios fetches to be

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

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

Re: [Nouveau] [Mesa-dev] gallium state tracker calls calloc for 0 sizes arrays ?

On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 27-08-15 15:46, Marek Olšák wrote: On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede hdego...@redhat.com wrote: Hi All, While

[Nouveau] [PATCH] nv50: avoid using inline vertex data submit when gl_VertexID is used

The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid-drawarrays Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: 11.0 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/nv50/nv50_program.c| 1 + src/gallium

Re: [Nouveau] [PATCH] nv50: avoid using inline vertex data submit when gl_VertexID is used

On Mon, Aug 24, 2015 at 11:57 AM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: On 24.08.2015 17:51, Ilia Mirkin wrote: The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid-drawarrays Signed-off-by: Ilia

Re: [Nouveau] [Mesa-dev] [PATCH] nv50: avoid using inline vertex data submit when gl_VertexID is used

-by: Samuel Pitoiset samuel.pitoi...@gmail.com This fix is simpler than I was expected. What about the edge flag stuff now? :) On 08/24/2015 05:51 PM, Ilia Mirkin wrote: The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid

[Nouveau] [PATCH] nvc0: make use of conservative depth info for forcing early z tests

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Entirely untested as there are no piglit tests for this functionality. Won't push until some appear, but wanted to get it out there. .../drivers/nouveau/codegen/nv50_ir_driver.h | 2 +- .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp

Re: [Nouveau] [Mesa-dev] [PATCH 1/2] nvc0/ir: detect AND/SHR pairs and convert into EXTBF

On Tue, Aug 18, 2015 at 9:57 PM, Matt Turner matts...@gmail.com wrote: On Tue, Aug 18, 2015 at 6:49 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Some shaders appear to extract bits using shift/and combos. Detect (some) of those and convert to EXTBF instead. What is EXTBF? Extract byte to float

[Nouveau] [PATCH 1/2] nvc0/ir: detect AND/SHR pairs and convert into EXTBF

Some shaders appear to extract bits using shift/and combos. Detect (some) of those and convert to EXTBF instead. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 66 +++--- 1 file changed, 46 insertions(+), 20 deletions

[Nouveau] [PATCH 2/2] nvc0/ir: detect i2f/i2i which operate on specific bytes/words

of that. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 + .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 4 ++ .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 79

Re: [Nouveau] [PATCH] glsl: Extend lowering pass for gl_ClipDistance to support other arrays

I said this on IRC, but I'll say it here too: (a) please regenerate this with -M (not in the general case, but it makes sense here) (b) this seems odd as there's no support for cull distance elsewhere yet. should be part of a series that adds cull distance support. right now there is none, so

[Nouveau] [PATCH] fb/sddr3: add WR/CWL values seen on a GK208

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Seen on my GK208. Trace available at http://people.freedesktop.org/~imirkin/traces/gk208/gk208-mmiotrace.log.xz Thanks to Roy for his assistance on finding the parameters. I tested this on top of his patch bios/rammap: Identify DLLoff

[Nouveau] [PATCH] nv50, nvc0: take level into account when doing eng2d multi-layer blits

This fixes arb_get_texture_sub_image-get, and any situation where the 2d engine was being used for multi-layer blits to a non-0 level. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.6 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/nv50/nv50_surface.c | 14

[Nouveau] [PATCH v2] nvc0: bind a fake tess control program when there isn't one available

Apparently this is necessary in order for tess factors to work in a tess eval program without a tess control program bound. Probably because it uses the fake program's shader header to work out the number of patch constants. Fixes vs-tes-tessinner-tessouter-inputs Signed-off-by: Ilia Mirkin imir

Re: [Nouveau] Fermi+ shader header docs

} 0x EXPORT_EN_1 = 0 0x EXPORT_EN_2 = 0 0x EXPORT_EN_3 = 0 0x EXPORT_EN_4 = 0 0x EXPORT_EN_5 = { CLIP_DISTANCE = 0 | UNK12 = 0 } 0x 19 = 0 Anything that we need to also be setting? -ilia On Mon, Jun 22, 2015 at 9:10 PM, Ilia Mirkin imir

Re: [Nouveau] DisplayPort support with 750 Ti

Supposed to? Sure! :) DP is finicky in general, and Maxwell is a fairly new generation that not a lot of people have tested or had access to, so quite expected for things to go wrong. Can you file a bug at bugs.freedesktop.org xorg - Driver/nouveau with the output of nouveau loaded with

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

On Mon, Aug 10, 2015 at 8:47 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 20:09, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego

Re: [Nouveau] Odd text behavior on Websites and others

On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can

Re: [Nouveau] Odd text behavior on Websites and others

wrote: Thanks - the only xorg.conf I found is - /usr/share/abrt/conf.d/plugins/xorg.conf Is this the file to be edited? -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote: On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com

Re: [Nouveau] Odd text behavior on Websites and others

for. find didn't help... I guess I'll have to run x config as root to get a xorg.conf which I can edit later... -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 11:42 -0400, Ilia Mirkin wrote: No, you probably want something in /etc/X11... a lot of the time it's split up

Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()

that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Alexandre, could

Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()

Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote: Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the

Re: [Nouveau] [PATCH] Take shift in crtc positions for ZaphodHeads configs into account.

I don't understand this patch (what are all these masks? how are they used?), and don't want to invest the time required to do so. However Mario is probably the sole serious user of ZaphodHeads, and if it fixes issues for him, probably fixes issues for others who try and give up with ZaphodHeads.

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example

<    2   3   4   5   6   7   8   9   10   11   >