[Nouveau] NVAC "No Signal"

2016-10-17 Thread poma 
Fixes "No Signal" via HDMI from NVIDIA Corporation ION VGA (rev b1)

Ref.
"drm/nouveau/disp/g94: implement workaround for dvi issue on fx380"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a4bd8a

The last working Fedora kernel 4.8.0-0.rc0.git3.1.fc25

Patched and tested with:
$ modinfo -n nouveau
/lib/modules/4.8.2-300.fc25.x86_64/updates/nouveau.ko

Tested-by: poma 
---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
index fbb8c7d..c9e40e7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c
@@ -434,7 +434,8 @@ nv50_disp_dptmds_war(struct nvkm_device *device)
case 0x96:
case 0x98:
case 0xaa:
-   case 0xac:
+/* NVIDIA MCP79/MCP7A "No Signal" */
+/* case 0xac:*/
return true;
default:
break;
-- 
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v5 0/3] drm/nouveau: set DMA mask before mapping scratch page

2016-10-17 Thread Alexandre Courbot 
On Mon, Oct 17, 2016 at 5:12 AM, Ard Biesheuvel
 wrote:
> On 7 October 2016 at 09:12, Alexandre Courbot  wrote:
>> On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel
>>  wrote:
>>> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that
>>> both GF 100 and NV50 are affected by the same issue, and that a related 
>>> issue
>>> has been solved already for Tegra in commit 9d0394c6bed5
>>> ("drm/nouveau/instmem/gk20a: set DMA mask early").
>>>
>>> The issue that this series addresses is the fact that the Nouveau driver
>>> invokes the DMA API before setting the DMA mask. In both cases addressed
>>> here, these are simply static bidirectional mappings of scratch pages whose
>>> purpose is not well understood, and in most cases, it does not matter that
>>> these pages are always allocated below 4 GB even if the hardware can access
>>> memory much higher up.
>>>
>>> However, on platforms without any RAM below 4 GB, the preliminary DMA mask
>>> of 32 is preventing the nouveau driver from loading on GF100 and NV50
>>> hardware with an error like the following one:
>>>
>>>nouveau :02:00.0: enabling device ( -> 0003)
>>>nouveau :02:00.0: NVIDIA GT218 (0a8280b1)
>>>nouveau :02:00.0: bios: version 70.18.a6.00.00
>>>nouveau :02:00.0: fb ctor failed, -14
>>>nouveau: probe of :02:00.0 failed with error -14
>>>
>>> So fix this by setting a preliminary DMA mask based on the MMU device 
>>> 'dma_bits'
>>> property (patch #1), and postpone mapping the scratch pages to the 
>>> respective
>>> FB .init() hooks. (#2 and #3)
>>>
>>> v5: move setting of preliminary DMA mask to nvkm_device_pci_new() (#1)
>>> move allocation and DMA mapping of scratch pages to .oneinit hooks (#2, 
>>> #3)
>>> v4: split and move dma_set_mask to probe hook (Alexander)
>>> v3: rework code to get rid of DMA_ERROR_CODE references, which is not
>>> defined on all architectures
>>> v2: replace incorrect comparison of dma_addr_t type var against NULL
>>>
>>> Ard Biesheuvel (3):
>>>   drm/nouveau: set streaming DMA mask early
>>>   drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit()
>>> hook
>>>   drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit()
>>> hook
>>
>> The series,
>>
>> Reviewed-by: Alexandre Courbot 
>>
>
> Thank you Alexandre.
>
> So is there a nouveau subtree this should go into? Or is it up to Dave
> to pull it into drm?

Ben already merged your patches into
https://github.com/skeggsb/nouveau/commits/master (and forgot to add
my Reviewed-by ;)). This repository will be merged into the next
kernel release.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau on a Jetson TK1 problems

2016-10-17 Thread Alexandre Courbot 
Hi,

On Mon, Oct 17, 2016 at 12:11 PM, ben  wrote:
> I hope this is a good mailing list for this problem. I have a Jetson TK1
> board and I am trying to get the nouveau drivers running on it without
> success. I am using the following:
>
> Nouveau linux kernel 4.8.0-rc4+
> Nouveau DRM git master
> xf86-video-nouveau git master
> Gnurou xserver  git branch GK20A
>
> My base system is Debian.
>
> When I try to start X I get:  X: drmmode_display.c:783: drmmode_crtc_init:
> Assertion `ret == 0' failed. There is also a kernel log message: [drm]
> Cannot find any crtc or sizes - going 1024x768

Posting your /var/log/Xorg.0.log would be most helpful at this point,
to understand which DDX is being used. On Tegra, you want to use the
modesetting DDX since the display device is driven by tegradrm and
thus not Nouveau-supported.

If you want any kind of acceleration, you will also need to patch X
for the same reason (see the two top commits at
https://github.com/Gnurou/xserver/commits/gk20a). GLamor can be used
with modesetting for hw acceleration, but this requires plugging the
display and rendering devices using PRIME (which X does not support
out-of-the-box at the moment).

These X patches in turn require the following kernel patch which is
not upstreamed yet:
https://github.com/Gnurou/linux/commit/8b06bf92b8da6bee92c3a2a8eaccd74ed3dd1939

Having to patch around is a bit boring, but once you get things
working X on TK1 is a rather pleasant experience (with or without
acceleration). Please let me know if anything is unclear!

Cheers,
Alex.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau on a Jetson TK1 problems

2016-10-17 Thread Karol Herbst 
2016-10-17 5:48 GMT+02:00 Ilia Mirkin :
> On Sun, Oct 16, 2016 at 11:39 PM, C Bergström  
> wrote:
>> Is there any particular reason you're not using the open source NVIDIA
>> Tegra drivers?
>>
>> This is what is being used for the TX1 (Sorry I don't know if it's the
>> same for the TK1)
>> http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=summary
>
> That's ... not particularly helpful. Presumably non-upstream and the
> fact that it's ancient are turn-offs. Either way, he seems to have a
> desire to try to get nouveau going.
>
>>
>> On Mon, Oct 17, 2016 at 11:11 AM, ben  wrote:
>>> I hope this is a good mailing list for this problem. I have a Jetson TK1
>>> board and I am trying to get the nouveau drivers running on it without
>>> success. I am using the following:
>>>
>>> Nouveau linux kernel 4.8.0-rc4+
>>> Nouveau DRM git master
>>> xf86-video-nouveau git master
>>> Gnurou xserver  git branch GK20A
>>>
>>> My base system is Debian.
>>>
>>> When I try to start X I get:  X: drmmode_display.c:783: drmmode_crtc_init:
>>> Assertion `ret == 0' failed. There is also a kernel log message: [drm]
>>> Cannot find any crtc or sizes - going 1024x768
>
> I don't think I've seen this before. The odd thing about the TK1 (and
> TX1, I believe), is that the GK20A device doesn't have any display
> capabilities - those are left up to tegra. Sounds like you're trying
> to use the nouveau ddx as the primary, which fails as there are no
> CRTC's. I believe Gnurou's xserver hacks rely on you using glamor (and
> thus the modesetting xorg ddx). Is that what you're using? Can you
> provide an xorg log?
>

Well it works like that basically:
modesetting DDX runs on top of the tegra 2d engine and 2d acceleration
is provided by prime offloaded glamor on top of mesa on the 3d engine
driven by nouveau.
Which basically means: remove xf86-video-nouveau

> Cheers,
>
>   -ilia
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/5] hwdefs: update nvc0_3d, add gm107_texture for new TIC format

2016-10-17 Thread Emil Velikov 
On 16 October 2016 at 20:14, Ilia Mirkin  wrote:
> These are copied directly from the mesa repository.
>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/hwdefs/gm107_texture.xml.h | 365 +
>  src/hwdefs/nvc0_3d.xml.h   | 867 
> +
>  2 files changed, 892 insertions(+), 340 deletions(-)
>  create mode 100644 src/hwdefs/gm107_texture.xml.h
Add this one to the EXTRA_DIST list in src/Makefile.am or it will be
missing in the release tarball.

-Emil
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/5] nvc0: refactor TIC uploads to allow different specifies per generation

2016-10-17 Thread Samuel Pitoiset 



On 10/17/2016 02:24 PM, Ilia Mirkin wrote:

On Mon, Oct 17, 2016 at 5:46 AM, Samuel Pitoiset
 wrote:

Few comments below.

On 10/16/2016 09:14 PM, Ilia Mirkin wrote:


This flips GM10x to using the updated format, which is what I tested
with. However GM20x and GP10x also use this TIC format.

Signed-off-by: Ilia Mirkin 
---
 src/nvc0_accel.c | 11 ++
 src/nvc0_accel.h | 56 ++
 src/nvc0_exa.c   | 22 ---
 src/nvc0_xv.c| 67
+++-
 4 files changed, 93 insertions(+), 63 deletions(-)

diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
index 0682806..8da5051 100644
--- a/src/nvc0_accel.c
+++ b/src/nvc0_accel.c
@@ -322,6 +322,17 @@ NVAccelInit3D_NVC0(ScrnInfoPtr pScrn)
PUSH_DATA (push, (bo->offset + MISC_OFFSET) >> 32);
PUSH_DATA (push, (bo->offset + MISC_OFFSET));
PUSH_DATA (push, 1);
+   } else {
+   /* Use new TIC format. Not strictly necessary for GM20x+
*/



Yes, but it's also enabled by default in mesa, looks fine.



+   IMMED_NVC0(push, SUBC_3D(0x0f10), 1);
+   if (pNv->dev->chipset >= 0x120) {
+   /* Use center sample locations. */
+   BEGIN_NVC0(push, SUBC_3D(0x11e0), 4);
+   PUSH_DATA (push, 0x);
+   PUSH_DATA (push, 0x);
+   PUSH_DATA (push, 0x);
+   PUSH_DATA (push, 0x);
+   }
}

BEGIN_NVC0(push, NVC0_3D(CODE_ADDRESS_HIGH), 2);
diff --git a/src/nvc0_accel.h b/src/nvc0_accel.h
index 607e97b..9378236 100644
--- a/src/nvc0_accel.h
+++ b/src/nvc0_accel.h
@@ -7,6 +7,7 @@
 #include "hwdefs/nvc0_m2mf.xml.h"
 #include "hwdefs/nv50_defs.xml.h"
 #include "hwdefs/nv50_texture.h"
+#include "hwdefs/gm107_texture.xml.h"
 #include "hwdefs/nv_3ddefs.xml.h"

 /* subchannel assignments, compatible with kepler's fixed layout  */
@@ -108,4 +109,59 @@ PUSH_DATAu(struct nouveau_pushbuf *push, struct
nouveau_bo *bo,
}
 }

+static __inline__ void
+PUSH_TIC(struct nouveau_pushbuf *push, struct nouveau_bo *bo, unsigned
offset,
+unsigned width, unsigned height, unsigned pitch, unsigned format)
+{
+   if (push->client->device->chipset < 0x110) {
+   unsigned tic2 = 0xd0001000;
+   if (pitch == 0)
+   tic2 |= 0x4000;
+   else
+   tic2 |= 0x0005c000;
+   PUSH_DATA(push, format);
+   PUSH_DATA(push, bo->offset + offset);
+   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
+   (bo->config.nvc0.tile_mode << 18) |
+   tic2);
+   PUSH_DATA(push, 0x0030);
+   PUSH_DATA(push, 0x8000 | width);
+   PUSH_DATA(push, 0x0001 | height);
+   PUSH_DATA (push, 0x0300);
+   PUSH_DATA (push, 0x);



Cosmetic.


Oops, will fix.





+   } else {
+   unsigned tile_mode = bo->config.nvc0.tile_mode;
+   PUSH_DATA(push, (format & 0x3f) | ((format & ~0x3f) <<
1));
+   PUSH_DATA(push, bo->offset + offset);
+   if (pitch == 0) {
+   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
+
GM107_TIC2_2_HEADER_VERSION_BLOCKLINEAR);
+   PUSH_DATA(push, GM107_TIC2_3_LOD_ANISO_QUALITY_2 |
+ (tile_mode & 0x007) |
+ (tile_mode & 0x070 >> (4 - 3)) |
+ (tile_mode & 0x700 >> (8 - 6)));
+   PUSH_DATA(push,
GM107_TIC2_4_SECTOR_PROMOTION_PROMOTE_TO_2_V |
+ GM107_TIC2_4_BORDER_SIZE_SAMPLER_COLOR |
+ GM107_TIC2_4_TEXTURE_TYPE_TWO_D |
+ (width - 1));
+   PUSH_DATA(push, GM107_TIC2_5_NORMALIZED_COORDS |
+   ((height - 1) & 0x));
+   PUSH_DATA(push,
GM107_TIC2_6_ANISO_FINE_SPREAD_FUNC_TWO |
+
GM107_TIC2_6_ANISO_COARSE_SPREAD_FUNC_ONE);
+   PUSH_DATA(push, 0x);
+   } else {
+   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
+
GM107_TIC2_2_HEADER_VERSION_PITCH);
+   PUSH_DATA(push, GM107_TIC2_3_LOD_ANISO_QUALITY_2 |
+   (pitch >> 5));
+   PUSH_DATA(push,
GM107_TIC2_4_BORDER_SIZE_SAMPLER_COLOR |
+
GM107_TIC2_4_TEXTURE_TYPE_TWO_D_NO_MIPMAP |
+ (width - 1));
+   PUSH_DATA(push, GM107_TIC2_5_NORMALIZED_COORDS |
(height - 1));
+   PUSH_DATA(push, 0x0);
+   PUSH_DATA(push,

Re: [Nouveau] [PATCH] exa: add GM10x acceleration support

2016-10-17 Thread Samuel Pitoiset 



On 10/17/2016 02:27 PM, Ilia Mirkin wrote:

On Mon, Oct 17, 2016 at 5:28 AM, Samuel Pitoiset
 wrote:

Looks reasonable, some minor comments below.


On 10/16/2016 02:06 AM, Ilia Mirkin wrote:

diff --git a/src/nvc0_exa.c b/src/nvc0_exa.c
index 6add60b..a53dfe6 100644
--- a/src/nvc0_exa.c
+++ b/src/nvc0_exa.c
@@ -914,14 +914,56 @@ NVC0EXAComposite(PixmapPtr pdpix,
if (!PUSH_SPACE(push, 64))
return;

+   if (pNv->dev->chipset >= 0x110) {
+   BEGIN_NVC0(push, NVC0_3D(CB_SIZE), 3);
+   PUSH_DATA (push, 256);
+   PUSH_DATA (push, (pNv->scratch->offset + PVP_DATA) >> 32);



No PUSH_DATAh in the DDX?


Nope. Didn't feel the burning need to add a helper either.


Fine by me.




 $(filter %nvc0.vpc,$(SHADERS)): %.vpc: %.vp
-   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -o $@
+   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gf100
-o $@
 $(filter %nvc0.fpc,$(SHADERS)): %.fpc: %.fp
-   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -o $@
+   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gf100
-o $@

 $(filter %nve0.vpc,$(SHADERS)): %.vpc: %.vp
-   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -V nve4 -o
$@
+   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gk104
-o $@
 $(filter %nve0.fpc,$(SHADERS)): %.fpc: %.fp
-   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -V nve4 -o
$@
+   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gk104
-o $@



This is unrelated to your main change, but well should be *exactly* the same
thing. :)


You mean the bit about me adding -V gf100? Figured I'd fix it up while
I was at it. The machine/variant names changed though.


Yeah, I won't ask for a separate patch anyways. :-)








 $(filter %nvf0.vpc,$(SHADERS)): %.vpc: %.vp
cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gk110 -o $@
 $(filter %nvf0.fpc,$(SHADERS)): %.fpc: %.fp
cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gk110 -o $@
+
+$(filter %nv110.vpc,$(SHADERS)): %.vpc: %.vp
+   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gm107 -o $@
+$(filter %nv110.fpc,$(SHADERS)): %.fpc: %.fp
+   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gm107 -o $@
diff --git a/src/shader/exac8nv110.fp b/src/shader/exac8nv110.fp
new file mode 100644
index 000..ce78036
--- /dev/null
+++ b/src/shader/exac8nv110.fp
@@ -0,0 +1,47 @@
+#ifndef ENVYAS
+static uint32_t
+NV110FP_Composite_A8[] = {
+   0x1462,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x8000,
+   0x0a0a,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x,
+   0x000f,
+   0x,
+#include "exac8nv110.fpc"
+};
+#else
+
+sched (st 0x0) (st 0x0) (st 0x0)



Those sched codes are definitely bad, but let's keep them as it for now. I
might have a look at some point to improve the thing.


Yeah, way wrong. However it's what our compiler would produce. You can
use this as a proving ground for your various theories. All simple
shaders though, no control flow. Only complex thing is textures.

  -ilia



--
-Samuel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] exa: add GM10x acceleration support

2016-10-17 Thread Ilia Mirkin 
On Mon, Oct 17, 2016 at 5:28 AM, Samuel Pitoiset
 wrote:
> Looks reasonable, some minor comments below.
>
>
> On 10/16/2016 02:06 AM, Ilia Mirkin wrote:
>> diff --git a/src/nvc0_exa.c b/src/nvc0_exa.c
>> index 6add60b..a53dfe6 100644
>> --- a/src/nvc0_exa.c
>> +++ b/src/nvc0_exa.c
>> @@ -914,14 +914,56 @@ NVC0EXAComposite(PixmapPtr pdpix,
>> if (!PUSH_SPACE(push, 64))
>> return;
>>
>> +   if (pNv->dev->chipset >= 0x110) {
>> +   BEGIN_NVC0(push, NVC0_3D(CB_SIZE), 3);
>> +   PUSH_DATA (push, 256);
>> +   PUSH_DATA (push, (pNv->scratch->offset + PVP_DATA) >> 32);
>
>
> No PUSH_DATAh in the DDX?

Nope. Didn't feel the burning need to add a helper either.

>>  $(filter %nvc0.vpc,$(SHADERS)): %.vpc: %.vp
>> -   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -o $@
>> +   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gf100
>> -o $@
>>  $(filter %nvc0.fpc,$(SHADERS)): %.fpc: %.fp
>> -   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -o $@
>> +   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gf100
>> -o $@
>>
>>  $(filter %nve0.vpc,$(SHADERS)): %.vpc: %.vp
>> -   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -V nve4 -o
>> $@
>> +   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gk104
>> -o $@
>>  $(filter %nve0.fpc,$(SHADERS)): %.fpc: %.fp
>> -   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m nvc0 -V nve4 -o
>> $@
>> +   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gf100 -V gk104
>> -o $@
>
>
> This is unrelated to your main change, but well should be *exactly* the same
> thing. :)

You mean the bit about me adding -V gf100? Figured I'd fix it up while
I was at it. The machine/variant names changed though.

>
>
>>
>>  $(filter %nvf0.vpc,$(SHADERS)): %.vpc: %.vp
>> cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gk110 -o $@
>>  $(filter %nvf0.fpc,$(SHADERS)): %.fpc: %.fp
>> cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gk110 -o $@
>> +
>> +$(filter %nv110.vpc,$(SHADERS)): %.vpc: %.vp
>> +   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gm107 -o $@
>> +$(filter %nv110.fpc,$(SHADERS)): %.fpc: %.fp
>> +   cpp -DENVYAS $< | sed -e '/^#/d' | $(ENVYAS) -w -m gm107 -o $@
>> diff --git a/src/shader/exac8nv110.fp b/src/shader/exac8nv110.fp
>> new file mode 100644
>> index 000..ce78036
>> --- /dev/null
>> +++ b/src/shader/exac8nv110.fp
>> @@ -0,0 +1,47 @@
>> +#ifndef ENVYAS
>> +static uint32_t
>> +NV110FP_Composite_A8[] = {
>> +   0x1462,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x8000,
>> +   0x0a0a,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x,
>> +   0x000f,
>> +   0x,
>> +#include "exac8nv110.fpc"
>> +};
>> +#else
>> +
>> +sched (st 0x0) (st 0x0) (st 0x0)
>
>
> Those sched codes are definitely bad, but let's keep them as it for now. I
> might have a look at some point to improve the thing.

Yeah, way wrong. However it's what our compiler would produce. You can
use this as a proving ground for your various theories. All simple
shaders though, no control flow. Only complex thing is textures.

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/5] nvc0: refactor TIC uploads to allow different specifies per generation

2016-10-17 Thread Ilia Mirkin 
On Mon, Oct 17, 2016 at 5:46 AM, Samuel Pitoiset
 wrote:
> Few comments below.
>
> On 10/16/2016 09:14 PM, Ilia Mirkin wrote:
>>
>> This flips GM10x to using the updated format, which is what I tested
>> with. However GM20x and GP10x also use this TIC format.
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/nvc0_accel.c | 11 ++
>>  src/nvc0_accel.h | 56 ++
>>  src/nvc0_exa.c   | 22 ---
>>  src/nvc0_xv.c| 67
>> +++-
>>  4 files changed, 93 insertions(+), 63 deletions(-)
>>
>> diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
>> index 0682806..8da5051 100644
>> --- a/src/nvc0_accel.c
>> +++ b/src/nvc0_accel.c
>> @@ -322,6 +322,17 @@ NVAccelInit3D_NVC0(ScrnInfoPtr pScrn)
>> PUSH_DATA (push, (bo->offset + MISC_OFFSET) >> 32);
>> PUSH_DATA (push, (bo->offset + MISC_OFFSET));
>> PUSH_DATA (push, 1);
>> +   } else {
>> +   /* Use new TIC format. Not strictly necessary for GM20x+
>> */
>
>
> Yes, but it's also enabled by default in mesa, looks fine.
>
>
>> +   IMMED_NVC0(push, SUBC_3D(0x0f10), 1);
>> +   if (pNv->dev->chipset >= 0x120) {
>> +   /* Use center sample locations. */
>> +   BEGIN_NVC0(push, SUBC_3D(0x11e0), 4);
>> +   PUSH_DATA (push, 0x);
>> +   PUSH_DATA (push, 0x);
>> +   PUSH_DATA (push, 0x);
>> +   PUSH_DATA (push, 0x);
>> +   }
>> }
>>
>> BEGIN_NVC0(push, NVC0_3D(CODE_ADDRESS_HIGH), 2);
>> diff --git a/src/nvc0_accel.h b/src/nvc0_accel.h
>> index 607e97b..9378236 100644
>> --- a/src/nvc0_accel.h
>> +++ b/src/nvc0_accel.h
>> @@ -7,6 +7,7 @@
>>  #include "hwdefs/nvc0_m2mf.xml.h"
>>  #include "hwdefs/nv50_defs.xml.h"
>>  #include "hwdefs/nv50_texture.h"
>> +#include "hwdefs/gm107_texture.xml.h"
>>  #include "hwdefs/nv_3ddefs.xml.h"
>>
>>  /* subchannel assignments, compatible with kepler's fixed layout  */
>> @@ -108,4 +109,59 @@ PUSH_DATAu(struct nouveau_pushbuf *push, struct
>> nouveau_bo *bo,
>> }
>>  }
>>
>> +static __inline__ void
>> +PUSH_TIC(struct nouveau_pushbuf *push, struct nouveau_bo *bo, unsigned
>> offset,
>> +unsigned width, unsigned height, unsigned pitch, unsigned format)
>> +{
>> +   if (push->client->device->chipset < 0x110) {
>> +   unsigned tic2 = 0xd0001000;
>> +   if (pitch == 0)
>> +   tic2 |= 0x4000;
>> +   else
>> +   tic2 |= 0x0005c000;
>> +   PUSH_DATA(push, format);
>> +   PUSH_DATA(push, bo->offset + offset);
>> +   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
>> +   (bo->config.nvc0.tile_mode << 18) |
>> +   tic2);
>> +   PUSH_DATA(push, 0x0030);
>> +   PUSH_DATA(push, 0x8000 | width);
>> +   PUSH_DATA(push, 0x0001 | height);
>> +   PUSH_DATA (push, 0x0300);
>> +   PUSH_DATA (push, 0x);
>
>
> Cosmetic.

Oops, will fix.

>
>
>> +   } else {
>> +   unsigned tile_mode = bo->config.nvc0.tile_mode;
>> +   PUSH_DATA(push, (format & 0x3f) | ((format & ~0x3f) <<
>> 1));
>> +   PUSH_DATA(push, bo->offset + offset);
>> +   if (pitch == 0) {
>> +   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
>> +
>> GM107_TIC2_2_HEADER_VERSION_BLOCKLINEAR);
>> +   PUSH_DATA(push, GM107_TIC2_3_LOD_ANISO_QUALITY_2 |
>> + (tile_mode & 0x007) |
>> + (tile_mode & 0x070 >> (4 - 3)) |
>> + (tile_mode & 0x700 >> (8 - 6)));
>> +   PUSH_DATA(push,
>> GM107_TIC2_4_SECTOR_PROMOTION_PROMOTE_TO_2_V |
>> + GM107_TIC2_4_BORDER_SIZE_SAMPLER_COLOR |
>> + GM107_TIC2_4_TEXTURE_TYPE_TWO_D |
>> + (width - 1));
>> +   PUSH_DATA(push, GM107_TIC2_5_NORMALIZED_COORDS |
>> +   ((height - 1) & 0x));
>> +   PUSH_DATA(push,
>> GM107_TIC2_6_ANISO_FINE_SPREAD_FUNC_TWO |
>> +
>> GM107_TIC2_6_ANISO_COARSE_SPREAD_FUNC_ONE);
>> +   PUSH_DATA(push, 0x);
>> +   } else {
>> +   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
>> +
>> GM107_TIC2_2_HEADER_VERSION_PITCH);
>> +   PUSH_DATA(push, GM107_TIC2_3_LOD_ANISO_QUALITY_2 |
>> +   (pitch >> 5));
>> +   PUSH_DATA(push,
>> GM107_TIC2_4_BORDER_SIZE_SAMPLER_COLOR |
>>

[Nouveau] [Bug 94990] [GM204] GTX 970 + 4GB VRAM fails at secboot (v4.6+)

2016-10-17 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94990

--- Comment #75 from Yann Golanski  ---
(In reply to Karol Herbst from comment #74)
> (In reply to Yann Golanski from comment #73)
> > (In reply to Karol Herbst from comment #72)
> > > By the way, this affects the kernel module only.
> > 
> > This still stops my machine from booting or X11 from running if I disable
> > the Nouveau driver. Or am I being dense and missing something?… ☺
> 
> most likely, yes. You should check dmesg in this case and check what is
> happening.

Err… If I disable Nouveau, I get no X11 at all. If I leave it enabled, the
machine does not boot.

Is there a way to boot with a kernel 4.6X and have X11 work via Nouveau?

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

Re: [Nouveau] [PATCH 5/5] recognize and accelerate GM20x

2016-10-17 Thread Samuel Pitoiset 

This requires at least a quick test. :-)

Acked-by: Samuel Pitoiset 

On 10/16/2016 09:14 PM, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---

Untested. I don't have the hardware.

 src/nv_driver.c  |  2 ++
 src/nvc0_accel.c | 10 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/nv_driver.c b/src/nv_driver.c
index fff83f8..61940a8 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -390,6 +390,7 @@ NVHasKMS(struct pci_device *pci_dev, struct 
xf86_platform_device *platform_dev)
case 0xf0:
case 0x100:
case 0x110:
+   case 0x120:
break;
default:
xf86DrvMsg(-1, X_ERROR, "Unknown chipset: NV%02X\n", chipset);
@@ -941,6 +942,7 @@ NVPreInit(ScrnInfoPtr pScrn, int flags)
pNv->Architecture = NV_KEPLER;
break;
case 0x110:
+   case 0x120:
pNv->Architecture = NV_MAXWELL;
break;
default:
diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
index 8da5051..996fb88 100644
--- a/src/nvc0_accel.c
+++ b/src/nvc0_accel.c
@@ -236,9 +236,17 @@ NVAccelInit3D_NVC0(ScrnInfoPtr pScrn)
} else if (pNv->dev->chipset < 0x110) {
class  = 0xa197;
handle = 0x906e;
-   } else {
+   } else if (pNv->dev->chipset < 0x120) {
class  = 0xb097;
handle = 0x906e;
+   } else if (pNv->dev->chipset < 0x130) {
+   class  = 0xb197;
+   handle = 0x906e;
+   } else {
+   xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+  "No 3D acceleration support for NV%X\n",
+  pNv->dev->chipset);
+   return FALSE;
}

ret = nouveau_object_new(pNv->channel, class, class,



--
-Samuel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/5] nvc0: refactor TIC uploads to allow different specifies per generation

2016-10-17 Thread Samuel Pitoiset 

Few comments below.

On 10/16/2016 09:14 PM, Ilia Mirkin wrote:

This flips GM10x to using the updated format, which is what I tested
with. However GM20x and GP10x also use this TIC format.

Signed-off-by: Ilia Mirkin 
---
 src/nvc0_accel.c | 11 ++
 src/nvc0_accel.h | 56 ++
 src/nvc0_exa.c   | 22 ---
 src/nvc0_xv.c| 67 +++-
 4 files changed, 93 insertions(+), 63 deletions(-)

diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
index 0682806..8da5051 100644
--- a/src/nvc0_accel.c
+++ b/src/nvc0_accel.c
@@ -322,6 +322,17 @@ NVAccelInit3D_NVC0(ScrnInfoPtr pScrn)
PUSH_DATA (push, (bo->offset + MISC_OFFSET) >> 32);
PUSH_DATA (push, (bo->offset + MISC_OFFSET));
PUSH_DATA (push, 1);
+   } else {
+   /* Use new TIC format. Not strictly necessary for GM20x+ */


Yes, but it's also enabled by default in mesa, looks fine.


+   IMMED_NVC0(push, SUBC_3D(0x0f10), 1);
+   if (pNv->dev->chipset >= 0x120) {
+   /* Use center sample locations. */
+   BEGIN_NVC0(push, SUBC_3D(0x11e0), 4);
+   PUSH_DATA (push, 0x);
+   PUSH_DATA (push, 0x);
+   PUSH_DATA (push, 0x);
+   PUSH_DATA (push, 0x);
+   }
}

BEGIN_NVC0(push, NVC0_3D(CODE_ADDRESS_HIGH), 2);
diff --git a/src/nvc0_accel.h b/src/nvc0_accel.h
index 607e97b..9378236 100644
--- a/src/nvc0_accel.h
+++ b/src/nvc0_accel.h
@@ -7,6 +7,7 @@
 #include "hwdefs/nvc0_m2mf.xml.h"
 #include "hwdefs/nv50_defs.xml.h"
 #include "hwdefs/nv50_texture.h"
+#include "hwdefs/gm107_texture.xml.h"
 #include "hwdefs/nv_3ddefs.xml.h"

 /* subchannel assignments, compatible with kepler's fixed layout  */
@@ -108,4 +109,59 @@ PUSH_DATAu(struct nouveau_pushbuf *push, struct nouveau_bo 
*bo,
}
 }

+static __inline__ void
+PUSH_TIC(struct nouveau_pushbuf *push, struct nouveau_bo *bo, unsigned offset,
+unsigned width, unsigned height, unsigned pitch, unsigned format)
+{
+   if (push->client->device->chipset < 0x110) {
+   unsigned tic2 = 0xd0001000;
+   if (pitch == 0)
+   tic2 |= 0x4000;
+   else
+   tic2 |= 0x0005c000;
+   PUSH_DATA(push, format);
+   PUSH_DATA(push, bo->offset + offset);
+   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
+   (bo->config.nvc0.tile_mode << 18) |
+   tic2);
+   PUSH_DATA(push, 0x0030);
+   PUSH_DATA(push, 0x8000 | width);
+   PUSH_DATA(push, 0x0001 | height);
+   PUSH_DATA (push, 0x0300);
+   PUSH_DATA (push, 0x);


Cosmetic.


+   } else {
+   unsigned tile_mode = bo->config.nvc0.tile_mode;
+   PUSH_DATA(push, (format & 0x3f) | ((format & ~0x3f) << 1));
+   PUSH_DATA(push, bo->offset + offset);
+   if (pitch == 0) {
+   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
+ GM107_TIC2_2_HEADER_VERSION_BLOCKLINEAR);
+   PUSH_DATA(push, GM107_TIC2_3_LOD_ANISO_QUALITY_2 |
+ (tile_mode & 0x007) |
+ (tile_mode & 0x070 >> (4 - 3)) |
+ (tile_mode & 0x700 >> (8 - 6)));
+   PUSH_DATA(push, 
GM107_TIC2_4_SECTOR_PROMOTION_PROMOTE_TO_2_V |
+ GM107_TIC2_4_BORDER_SIZE_SAMPLER_COLOR |
+ GM107_TIC2_4_TEXTURE_TYPE_TWO_D |
+ (width - 1));
+   PUSH_DATA(push, GM107_TIC2_5_NORMALIZED_COORDS |
+   ((height - 1) & 0x));
+   PUSH_DATA(push, GM107_TIC2_6_ANISO_FINE_SPREAD_FUNC_TWO 
|
+   
GM107_TIC2_6_ANISO_COARSE_SPREAD_FUNC_ONE);
+   PUSH_DATA(push, 0x);
+   } else {
+   PUSH_DATA(push, ((bo->offset + offset) >> 32) |
+   GM107_TIC2_2_HEADER_VERSION_PITCH);
+   PUSH_DATA(push, GM107_TIC2_3_LOD_ANISO_QUALITY_2 |
+   (pitch >> 5));
+   PUSH_DATA(push, GM107_TIC2_4_BORDER_SIZE_SAMPLER_COLOR |
+ GM107_TIC2_4_TEXTURE_TYPE_TWO_D_NO_MIPMAP |
+ (width - 1));
+   PUSH_DATA(push, GM107_TIC2_5_NORMALIZED_COORDS | 
(height - 1));
+   PUSH_DATA(push, 0x0);
+   PUSH_DATA(push, 0x0);

Re: [Nouveau] [PATCH 3/5] nvc0: rename BEGIN_IMC0 to IMMED_NVC0

2016-10-17 Thread Samuel Pitoiset 

Reviewed-by: Samuel Pitoiset 

On 10/16/2016 09:14 PM, Ilia Mirkin wrote:

For consistency with mesa. It wasn't used anywhere previously.

Signed-off-by: Ilia Mirkin 
---
 src/nouveau_local.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nouveau_local.h b/src/nouveau_local.h
index 3de69a2..dd49395 100644
--- a/src/nouveau_local.h
+++ b/src/nouveau_local.h
@@ -237,7 +237,7 @@ BEGIN_NIC0(struct nouveau_pushbuf *push, int subc, int 
mthd, int size)
 }

 static inline void
-BEGIN_IMC0(struct nouveau_pushbuf *push, int subc, int mthd, int data)
+IMMED_NVC0(struct nouveau_pushbuf *push, int subc, int mthd, int data)
 {
PUSH_DATA (push, 0x8000 | (data << 16) | (subc << 13) | (mthd / 4));
 }



--
-Samuel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/5] hwdefs: update nvc0_3d, add gm107_texture for new TIC format

2016-10-17 Thread Samuel Pitoiset 

Acked-by: Samuel Pitoiset 

On 10/16/2016 09:14 PM, Ilia Mirkin wrote:

These are copied directly from the mesa repository.

Signed-off-by: Ilia Mirkin 
---
 src/hwdefs/gm107_texture.xml.h | 365 +
 src/hwdefs/nvc0_3d.xml.h   | 867 +
 2 files changed, 892 insertions(+), 340 deletions(-)
 create mode 100644 src/hwdefs/gm107_texture.xml.h

diff --git a/src/hwdefs/gm107_texture.xml.h b/src/hwdefs/gm107_texture.xml.h
new file mode 100644
index 000..a4bc380
--- /dev/null
+++ b/src/hwdefs/gm107_texture.xml.h
@@ -0,0 +1,365 @@
+#ifndef GM107_TEXTURE_XML
+#define GM107_TEXTURE_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://github.com/envytools/envytools/
+git clone https://github.com/envytools/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- /home/skeggsb/git/envytools/rnndb/../rnndb/graph/gm107_texture.xml (  22057 
bytes, from 2016-02-12 03:01:43)
+- /home/skeggsb/git/envytools/rnndb/copyright.xml(   6456 
bytes, from 2015-09-10 02:57:40)
+- /home/skeggsb/git/envytools/rnndb/nvchipsets.xml   (   2908 
bytes, from 2016-02-04 22:19:11)
+- /home/skeggsb/git/envytools/rnndb/g80_defs.xml (  21739 
bytes, from 2016-02-04 00:29:42)
+
+Copyright (C) 2006-2016 by the following authors:
+- Artur Huillet  (ahuillet)
+- Ben Skeggs (darktama, darktama_)
+- B. R.  (koala_br)
+- Carlos Martin  (carlosmn)
+- Christoph Bumiller  (calim, chrisbmr)
+- Dawid Gajownik  (gajownik)
+- Dmitry Baryshkov
+- Dmitry Eremin-Solenikov  (lumag)
+- EdB  (edb_)
+- Erik Waling  (erikwaling)
+- Francisco Jerez  (curro)
+- Ilia Mirkin  (imirkin)
+- jb17bsome  (jb17bsome)
+- Jeremy Kolb  (kjeremy)
+- Laurent Carlier  (lordheavy)
+- Luca Barbieri  (lb, lb1)
+- Maarten Maathuis  (stillunknown)
+- Marcin Kościelnicki  (mwk, koriakin)
+- Mark Carey  (careym)
+- Matthieu Castet  (mat-c)
+- nvidiaman  (nvidiaman)
+- Patrice Mandin  (pmandin, pmdata)
+- Pekka Paalanen  (pq, ppaalanen)
+- Peter Popov  (ironpeter)
+- Richard Hughes  (hughsient)
+- Rudi Cilibrasi  (cilibrar)
+- Serge Martin
+- Simon Raffeiner
+- Stephane Loeuillet  (leroutier)
+- Stephane Marchesin  (marcheu)
+- sturmflut  (sturmflut)
+- Sylvain Munaut 
+- Victor Stinner  (haypo)
+- Wladmir van der Laan  (miathan6)
+- Younes Manton  (ymanton)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+#define GM107_TIC2__SIZE   0x0020
+#define GM107_TIC2_0   0x
+#define GM107_TIC2_0_COMPONENTS_SIZES__MASK0x007f
+#define GM107_TIC2_0_COMPONENTS_SIZES__SHIFT   0
+#define GM107_TIC2_0_COMPONENTS_SIZES_R32_G32_B32_A32  0x0001
+#define GM107_TIC2_0_COMPONENTS_SIZES_R32_G32_B32  0x0002
+#define GM107_TIC2_0_COMPONENTS_SIZES_R16_G16_B16_A16  0x0003
+#define GM107_TIC2_0_COMPONENTS_SIZES_R32_G32  0x0004
+#define GM107_TIC2_0_COMPONENTS_SIZES_R32_B24G8
0x0005
+#define

Re: [Nouveau] [PATCH 2/5] nvc0: make use of the new hwdefs for TEX_CB_INDEX

2016-10-17 Thread Samuel Pitoiset 

Reviewed-by: Samuel Pitoiset 

On 10/16/2016 09:14 PM, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---
 src/nvc0_accel.c | 2 +-
 src/nvc0_accel.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
index 52a17db..0682806 100644
--- a/src/nvc0_accel.c
+++ b/src/nvc0_accel.c
@@ -313,7 +313,7 @@ NVAccelInit3D_NVC0(ScrnInfoPtr pScrn)
PUSH_DATA (push, 0x0001);
BEGIN_NVC0(push, NVC0_3D(CB_BIND(4)), 1);
PUSH_DATA (push, 0x11);
-   BEGIN_NVC0(push, SUBC_3D(0x2608), 1);
+   BEGIN_NVC0(push, NVE4_3D(TEX_CB_INDEX), 1);
PUSH_DATA (push, 1);
}

diff --git a/src/nvc0_accel.h b/src/nvc0_accel.h
index 4c3bb0f..607e97b 100644
--- a/src/nvc0_accel.h
+++ b/src/nvc0_accel.h
@@ -12,6 +12,7 @@
 /* subchannel assignments, compatible with kepler's fixed layout  */
 #define SUBC_3D(mthd)0, (mthd)
 #define NVC0_3D(mthd)SUBC_3D(NVC0_3D_##mthd)
+#define NVE4_3D(mthd)SUBC_3D(NVE4_3D_##mthd)
 #define SUBC_M2MF(mthd)  2, (mthd)
 #define SUBC_P2MF(mthd)  2, (mthd)
 #define NVC0_M2MF(mthd)  SUBC_M2MF(NVC0_M2MF_##mthd)



--
-Samuel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] exa: add GM10x acceleration support

2016-10-17 Thread Samuel Pitoiset 

Looks reasonable, some minor comments below.

On 10/16/2016 02:06 AM, Ilia Mirkin wrote:

rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to
work. Very lightly tested.

Instead of sticking coordinates into pushbufs, the vertex shader is
modified to read them from a constbuf, indexed by vertex id. This
approach could be used for all nvc0 generations, but I didn't want to
rock the boat.

Signed-off-by: Ilia Mirkin 
---

Note: this won't work for GM20x - we need to allow TIC format to be updated
for that to work. But this is a step in that direction.

 src/Makefile.am   |  16 
 src/nouveau_copy.c|   1 +
 src/nouveau_exa.c |   2 +-
 src/nouveau_xv.c  |   2 +-
 src/nv_accel_common.c |   1 +
 src/nv_driver.c   |   1 +
 src/nvc0_accel.c  |  37 ++---
 src/nvc0_exa.c|  48 --
 src/nvc0_xv.c |  48 --
 src/shader/Makefile   |  23 ---
 src/shader/exac8nv110.fp  |  47 +
 src/shader/exac8nv110.fpc |  38 +
 src/shader/exacanv110.fp  |  47 +
 src/shader/exacanv110.fpc |  38 +
 src/shader/exacmnv110.fp  |  47 +
 src/shader/exacmnv110.fpc |  38 +
 src/shader/exas8nv110.fp  |  42 +++
 src/shader/exas8nv110.fpc |  28 +
 src/shader/exasanv110.fp  |  47 +
 src/shader/exasanv110.fpc |  38 +
 src/shader/exascnv110.fp  |  38 +
 src/shader/exascnv110.fpc |  20 +
 src/shader/videonv110.fp  |  54 
 src/shader/videonv110.fpc |  52 +++
 src/shader/xfrm2nv110.vp  |  82 +
 src/shader/xfrm2nv110.vpc | 102 ++
 26 files changed, 918 insertions(+), 19 deletions(-)
 create mode 100644 src/shader/exac8nv110.fp
 create mode 100644 src/shader/exac8nv110.fpc
 create mode 100644 src/shader/exacanv110.fp
 create mode 100644 src/shader/exacanv110.fpc
 create mode 100644 src/shader/exacmnv110.fp
 create mode 100644 src/shader/exacmnv110.fpc
 create mode 100644 src/shader/exas8nv110.fp
 create mode 100644 src/shader/exas8nv110.fpc
 create mode 100644 src/shader/exasanv110.fp
 create mode 100644 src/shader/exasanv110.fpc
 create mode 100644 src/shader/exascnv110.fp
 create mode 100644 src/shader/exascnv110.fpc
 create mode 100644 src/shader/videonv110.fp
 create mode 100644 src/shader/videonv110.fpc
 create mode 100644 src/shader/xfrm2nv110.vp
 create mode 100644 src/shader/xfrm2nv110.vpc

diff --git a/src/Makefile.am b/src/Makefile.am
index 1e04ddf..6ba8d87 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -77,48 +77,64 @@ EXTRA_DIST = hwdefs/nv_3ddefs.xml.h \
 shader/exac8nve0.fpc \
 shader/exac8nvf0.fp \
 shader/exac8nvf0.fpc \
+shader/exac8nv110.fp \
+shader/exac8nv110.fpc \
 shader/exacanvc0.fp \
 shader/exacanvc0.fpc \
 shader/exacanve0.fp \
 shader/exacanve0.fpc \
 shader/exacanvf0.fp \
 shader/exacanvf0.fpc \
+shader/exacanv110.fp \
+shader/exacanv110.fpc \
 shader/exacmnvc0.fp \
 shader/exacmnvc0.fpc \
 shader/exacmnve0.fp \
 shader/exacmnve0.fpc \
 shader/exacmnvf0.fp \
 shader/exacmnvf0.fpc \
+shader/exacmnv110.fp \
+shader/exacmnv110.fpc \
 shader/exas8nvc0.fp \
 shader/exas8nvc0.fpc \
 shader/exas8nve0.fp \
 shader/exas8nve0.fpc \
 shader/exas8nvf0.fp \
 shader/exas8nvf0.fpc \
+shader/exas8nv110.fp \
+shader/exas8nv110.fpc \
 shader/exasanvc0.fp \
 shader/exasanvc0.fpc \
 shader/exasanve0.fp \
 shader/exasanve0.fpc \
 shader/exasanvf0.fp \
 shader/exasanvf0.fpc \
+shader/exasanv110.fp \
+shader/exasanv110.fpc \
 shader/exascnvc0.fp \
 shader/exascnvc0.fpc \
 shader/exascnve0.fp \
 shader/exascnve0.fpc \
 shader/exascnvf0.fp \
 shader/exascnvf0.fpc \
+shader/exascnv110.fp \
+shader/exascnv110.fpc \
 shader/videonvc0.fp \
 shader/videonvc0.fpc \
 shader/videonve0.fp \
 shader/videonve0.fpc \
 shader/videonvf0.fp \
 shader/videonvf0.fpc \
+shader/videonv110.fp \
+shader/videonv110.fpc \
 shader/xfrm2nvc0.vp \
 shader/xfrm2nvc0.vpc \
 shader/xfrm2nve0.vp \
 shader/xfrm2nve0.vpc \
 shader/xfrm2nvf0.vp \
 shader/xfrm2nvf0.vpc \
+

Re: [Nouveau] [PATCH v5 0/3] drm/nouveau: set DMA mask before mapping scratch page

2016-10-17 Thread Karol Herbst 
Hi Ard,

the official nouveau tree is here: https://github.com/skeggsb/nouveau

But ben usually takes care of everything if you post the patches on the ML.
No idea what you discussed internally though, but alex also posts his suff
here.

On 16 Oct 2016 22:12, "Ard Biesheuvel"  wrote:

On 7 October 2016 at 09:12, Alexandre Courbot  wrote:
> On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel
>  wrote:
>> This v4 is now a 3 piece series (since v4), after Alexandre pointed out
that
>> both GF 100 and NV50 are affected by the same issue, and that a related
issue
>> has been solved already for Tegra in commit 9d0394c6bed5
>> ("drm/nouveau/instmem/gk20a: set DMA mask early").
>>
>> The issue that this series addresses is the fact that the Nouveau driver
>> invokes the DMA API before setting the DMA mask. In both cases addressed
>> here, these are simply static bidirectional mappings of scratch pages
whose
>> purpose is not well understood, and in most cases, it does not matter
that
>> these pages are always allocated below 4 GB even if the hardware can
access
>> memory much higher up.
>>
>> However, on platforms without any RAM below 4 GB, the preliminary DMA
mask
>> of 32 is preventing the nouveau driver from loading on GF100 and NV50
>> hardware with an error like the following one:
>>
>>nouveau :02:00.0: enabling device ( -> 0003)
>>nouveau :02:00.0: NVIDIA GT218 (0a8280b1)
>>nouveau :02:00.0: bios: version 70.18.a6.00.00
>>nouveau :02:00.0: fb ctor failed, -14
>>nouveau: probe of :02:00.0 failed with error -14
>>
>> So fix this by setting a preliminary DMA mask based on the MMU device
'dma_bits'
>> property (patch #1), and postpone mapping the scratch pages to the
respective
>> FB .init() hooks. (#2 and #3)
>>
>> v5: move setting of preliminary DMA mask to nvkm_device_pci_new() (#1)
>> move allocation and DMA mapping of scratch pages to .oneinit hooks
(#2, #3)
>> v4: split and move dma_set_mask to probe hook (Alexander)
>> v3: rework code to get rid of DMA_ERROR_CODE references, which is not
>> defined on all architectures
>> v2: replace incorrect comparison of dma_addr_t type var against NULL
>>
>> Ard Biesheuvel (3):
>>   drm/nouveau: set streaming DMA mask early
>>   drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit()
>> hook
>>   drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit()
>> hook
>
> The series,
>
> Reviewed-by: Alexandre Courbot 
>

Thank you Alexandre.

So is there a nouveau subtree this should go into? Or is it up to Dave
to pull it into drm?

Regards,
Ard.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau