search for: hdegoede

On Fri, Oct 2, 2015 at 3:35 AM, Hans de Goede <hdegoede at 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 <hdegoede at redhat.com> wrote: >>> >>> Hi, >>> >>> On 02-10-15 05:41, Ilia Mirkin 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 (nouveau) mesa patches merged. Should I request commit rights, and push my own patches once they have been reviewed ? Regards, Hans

On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Add support for clover / OpenCL kernel input parameters. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deleti...

...nv46 based cards. Change the mc subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is identical to the nv44 mc code except that it does not use msi (it does not define a msi_rearm callback). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435 Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c index c630136..b4ad791 100644 --- a/drivers/gpu/drm/nouv...

On Thu, Mar 10, 2016 at 10:27 AM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > > > On 03/10/2016 04:23 PM, Ilia Mirkin wrote: >> >> On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: >>> >>> Add support for clover / OpenCL kernel input parameters. >>> >>> Signed-off-by: Hans de Goede <hdegoede at redhat.com> >>> --- >>> .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 >...

The sifm object has a limit of 1024x1024 for its input size and 2048x2048 for its output. The code checking this was trying to be clever resulting in it seeing a surface of e.g 1024x256 being outside of the input size limit. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_transfer.c b/src/gallium/drivers/nouveau/nv30/nv30_transfer.c index 214da65..2452071 100644 --- a/src/gallium/drivers...

Hello, I'd like to recommend backporting this commit: commit 0a363e85cdafbceeee6a49b91c604d0d4d070dc7 Author: Hans de Goede <hdegoede at redhat.com> Date: Thu Jul 23 17:20:12 2015 +0200 drm/nouveau/nv46: Change mc subdev oclass from nv44 to nv4c This disables MSI by default on G72 (NV46) devices where it's apparently a bit buggy. We have a later patch which turns MSI back on with a quirk, but it isn't extremely...

From: Hans de Goede <hdegoede at redhat.com> I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. virtio_console's port_fops_poll checks port->inbuf != NULL to determine if read won...

From: Hans de Goede <hdegoede at redhat.com> I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. virtio_console's port_fops_poll checks port->inbuf != NULL to determine if read won...

The llvm TGSI backend does things like: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x Expecting the data at address TEMP[0].x to get loaded to TEMP[0].y. Before this commit the data at TEMP[0].x + 4 would be loaded instead. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index 557608e..cc51f5a 1...

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> 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 or assert(false). Which isn't grea...

...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 that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Use 1024x1024 blocks -Use the sifm on both nv3x and nv4x cards instead of only on nv3x cards --- src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 38 ++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/n...

acpi_video.c passed the ACPI_VIDEO_NOTIFY_* defines as type code to acpi_notifier_call_chain(). Move these defines to acpi/video.h so that acpi_notifier listeners can check the type code using these defines. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- drivers/acpi/acpi_video.c | 11 ----------- include/acpi/video.h | 11 +++++++++++ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index c5557d0..201292e 100644 --- a/drivers/acpi/acpi_video.c +++ b/d...

On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdegoede at redhat.com> 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 E[soffice.bin[3785]] validate: -12 > [...

Hi All, This series implements using double immediates in the nouveau codegen code. This turns the following (nvc0) code: 1: mov u32 $r2 0x00000000 (8) 2: mov u32 $r3 0x3fe00000 (8) 3: add f64 $r0d $r0d $r2d (8) Into: 1: add f64 $r0d $r0d 0.500000 (8) This has been tested with the 2 double shader tests which I just send to the piglet list. On a gk208 (gk110 / SM35)

LOAD loads upto 4 components from the specified resource starting at the passed in x value of the 2nd source operand, the y, z and w components of the address should not be used. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -New patch in v2 of this patch-set --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/...

...y commit msg, it gives the following example: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x This clearly is wrong, the last TEMP[0].x is not even valid TGSI, the correct example would be: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0] Regards, Hans > On Thu, Apr 7, 2016 at 9:27 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> The llvm TGSI backend does things like: >> >> >> >> Expecting the data at address TEMP[0].x to get loaded to >> TEMP[0].y. Before this commit the data at TEMP[0].x + 4 would be >> loaded instead. This commit fixes this. >>...

Hi, On 27-08-15 15:46, Marek Olšák wrote: > On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi All, >> >> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089 >> >> I made a apitrace recording of the a single slide transition >> animation, and since I suspected memory corruption replayed >> it using Elec...

Hi, On 24-07-15 04:32, Ben Skeggs wrote: > On 24 July 2015 at 01:20, Hans de Goede <hdegoede at redhat.com> wrote: >> MSI interrupts appear to not work for nv46 based cards. Change the mc >> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is >> identical to the nv44 mc code except that it does not use msi >> (it does not define a msi_rearm callb...

...ing code, but not all of it. Effectively all of it is dead already, if we ever enter the old code paths in handeLOAD / handleSTORE / handleATOM we will get an exception due to trying to access the now always zero-sized resources vector. Disable all the dead code. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Split out assert() on getFile() != BUFFER/MEMORY into a separate patch -Split out removal of TGSI_RESOURCE_* defines into a separate patch --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 d...