X.org 1.18.4 and newer

[ChristophHaag]

See https://archlinuxarm.org/forum/viewtopic.php?p=53358#p53358

For me, I get this assertion failing when trying to start X:

failed to add fb -6

and then

Xorg: xf86Helper.c:1942: xf86ScrnToScreen: Assertion `pScrn->scrnIndex < screenInfo.numScreens' failed.

1.18.3 works fine.

Even if you don't work on porting your patches to newer X.org versions, this info might be helpful for others who run into this issue.

[Gnurou]

Thankfully patching X will no longer be needed. By building a custom (read: quite hacked) Mesa we can use user-space programs as-is (which means KWin should also work - haven't tried yet though). I will try to push that tomorrow.

[ChristophHaag]

Oh cool, I'll try that then immediately.

The challenge is not kwin though, it's glamor.

Being a mesa hack, this would also work on wayland, right?

[Gnurou]

I have tested locally and GLamor also works thanks to that trick (it is Christian Gmeiner's renderonly series - we hope to get it merged officially into Mesa). I have tested kmscube, glmark2-drm, weston and X/GLamor and all were working (although with a few artefacts due to sync issues, but this should be fixable as well). Of course, EGL and GLX clients under Wayland and X were working as well.

So the new workflow will be compile kernel (no need to compile the out-of-tree Nouveau), and compile Mesa, and you should be done.

Stay tuned for more details tomorrow. :)

[Gnurou]

All updated. Please see the new instructions at https://github.com/NVIDIA/tegra-nouveau-rootfs/ . xserver 1.18.4 confirmed to work with this.

I am interested in hearing your feedback! Hopefully I will find a way to fix the tearing issue soon...

Closing this issue for now.

[ChristophHaag]

A question while it compiles: Does it require your kernel fork or would it be enough to set CONFIG_DRM_TEGRA_STAGING=y in the mainline kernel? I ask because on my nyan-big chromebook newer kernel versions aren't very stable, so I'm still using 4.5.

[Gnurou]

Provided you enable CONFIG_DRM_TEGRA_STAGING (hope to remove that requirement sometime soon) you should be ok with 4.5 on TK1 (TX1 requires something more recent I think)

[ChristophHaag]

I already had it enabled on my 4.5 kernel, but it only falls back to llvmpipe, both X and weston.

Here is a Xorg.0.log: https://gist.github.com/ChristophHaag/f952f38dd8e76b5a65fbc806bfa126b1

I used this PKGBUILD for mesa: https://gist.github.com/ChristophHaag/7ef70ed582f1776653ea8cf6c3294a04

I had a brief look at strace X and it does open tegra_dri.so, and I don't see obvious errors other than MESA-LOADER: failed to retrieve device information, which I assume is not fatal, so...

Any pointers where I could try debugging? Can you post a Xorg.0.log when it's working for comparison purposes?

[Gnurou]

The MESA-LOADER: failed to retrieve device information message is expected here, no need to worry about it.

Can you try the following:

1. Remove the swrast driver so it does not get used as a fallback (don't forget to rm the kms_swrast_dri.so and swrast_dri.so that have been installed by the previous build)
2. Build and run kmscube from my repo (Gnurou/kmscube master branch) and see whether it can run. If it does, then this means things are working
3. Try again with weston and X. Maybe the drivers are probed in the wrong order. In any case, without swrast you should get either acceleration or complete failure.

[ChristophHaag]

I made clean build with swrast removed from gallium drivers, and that only results in the swrast fallback not working:

[ChristophHaag]

I've single stepped a bit through mesa. Everything looks good until nouveau_drm_winsys.c:108 switch (dev->chipset & ~0xf) { where it fails because dev->chipset is 0.

The current value of *dev is {object = {parent = 0x3f8a8, handle = 18446744073709551615, oclass = 2147483648, length = 4294967295, data = 0x0}, fd = -1, lib_version = 0, drm_version = 0, chipset = 0, vram_size = 12884901888, gart_size = 17179869184, vram_limit = 10307921510, gart_limit = 13743895347}

In libdrm nouveau.c like 417 nvdev->base.chipset = v; is set with v having the value 4294967296 which works because v is an uint64_t, but when it gets assigned, to dev->chipset, which is an unsigned int, it becomes 0.

Not sure what to do with that...

Edit: Tried to set dev->chipset to 0xe0 (GK104) before the switch, but it still fails, this time with a printed error message: nvc0_screen_create:787 - Base screen init failed: -22. There's probably some underlying issue there...

[Gnurou]

Let's start with the obvious: what is the content of /dev/dri?

[Gnurou]

Just an idea, but the drivers loading order may be important here. Mesa will expect tegradrm to be loaded before Nouveau. Usually I achieve this by having tegradrm built into the kernel, and Nouveau as a module. /dev/dri/card0 will then be the tegradrm device, and /dev/dri/card1/dev/dri/renderD128 the Nouveau nodes.

[ChristophHaag]

card0, card1 and renderD128 is there, and with the previous X hack, it worked.

Your idea was probably right. udevadm info says that card0 is 57000000.gpu is and card1 is 50000000.host1x.

I tried blacklisting nouveau and loading it manually after boot and kmscube now fails with the message nvc0_screen_create:937 - Error allocating PGRAPH context for 3D: -22.

[Gnurou]

I really should remove this hardcoded card1 in the Mesa hack...

Mmm, so nvc0_screen_create() managed to create a 2d context, but not a 3d one? Interesting. Can you track what the value of obj_class is? On TK1 it should be 0xa297. I'm surprised it would not work though, especially since you reported the previous hack was working too...

Also, can you post a full dmesg?

[ChristophHaag]

Oh wait my mistake. I still had my dev->chipset = 0xe0; hack in there. Turns out this was probably the wrong GPU to simulate...

Now kmscube works!

In X and weston it doesn't work though. LIBGL_DEBUG=verbose says it's because of libGL error: failed to create dri screen.

[Gnurou]

Nice! For kmscube at least.

But now I would expect X and weston to work just the same, as they do on my system. You are using the Arch Linux packages and not custom-compiled packages, aren't you? Also from your use of a PKGBUILD I assume you only have one instance of Mesa installed, but could it be that there is another one lurking?

[ChristophHaag]

This is not the problem.

I single stepped some more and ret = nouveau_getparam(dev, NOUVEAU_GETPARAM_FB_SIZE, &v); and ret = nouveau_getparam(dev, NOUVEAU_GETPARAM_AGP_SIZE, &v); both return -13. That's permission denied. And indeed, when running glxgears -info as root, it runs on nouveau. So a simple permission issue is left to solve and it works! Great job!

[Gnurou]

Great! I may have spotted an issue though. Looks the output of glxinfo for the core GL version - it says 0 and seems to fallback to compat mode. I am not sure why this is so.

[ChristophHaag]

Works for me:

sudo glxinfo | grep OpenGL
libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVEA
OpenGL core profile version string: 4.1 (Core Profile) Mesa 13.1.0-devel (git-d2716d2560)
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.1.0-devel (git-d2716d2560)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 13.1.0-devel (git-d2716d2560)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

But I don't know what to do about permissions. I don't think it's a user space permission error, because it also happens when I chmod 777 /dev/dri/card1, I think it's the kernel rejecting it, maybe because of missing drm authorization? I don't know much about that...

[ChristophHaag]

Oh, I know. You are missing --enable-texture-float in your configure. Without that you don't get OpenGL 3+.

[Gnurou]

Aha, am I. Thanks for the hint, I think that's what prevents Plasma compositor to start (won't be able to confirm until next year though, grrr).

Regarding the permission issue, I am puzzled as well. Is your user in the video group? Maybe also have a look at the prepare-rootfs and distro/prepare-ArchLinuxArm scripts of https://github.com/NVIDIA/tegra-rootfs-scripts . I twiddle a lot of things in there and maybe there is something related.

If you chmod, make sure to also chmod renderD128 as Mesa may use one or the other depending on the context.

[ChristophHaag]

Huh. https://lists.freedesktop.org/archives/mesa-dev/2016-December/138963.html

[Gnurou]

This one should replace some of my dirty hacks with saner logic. Will test it as soon as I am back from holidays.

[ChristophHaag]

Suddenly everyone working on this? https://lists.x.org/archives/xorg-devel/2017-January/052218.html

[Gnurou]

I'm not going to complain about this! :) Thanks for the infos.