Graphics Acceleration Is Missing #2
Comments
The See:
Depending upon your bootloader, those files will need to be put on your initramfs or whatever the Android bootloader looks for. |
|
Thank you for your comment, I'll try to integrate the blob file in the kernel, or put it in the /lib folder. |
|
Mmm, @Echelon9 that doesn't seem to be the problem. The file is available at |
|
You'll want the full path to resolve to So in your approach, |
|
@denysvitali any update from your further testing? |
|
I'm trying to port the 4.14-rc1 kernel right now, afterwards I'll try with your suggestions. I'll report back soon! 👍 |
|
Here is the new 4.14-rc1 dmesg
|
|
May be helpful later: https://www.phoronix.com/scan.php?page=news_item&px=Tegra-2-Video-Decode-Driver-V3 |
|
Probably not, that relates to the older Tegra 2 GPUs. This device has a Maxwell series GPU. |
|
Yeah, realized after I posted. Brainfart :P |
|
Maybe @Gnurou can help us, somehow |
|
Mmm, everything seems to be in place, so I am not sure what happens here. I happen to own a Pixel C, so maybe I can try to reproduce and investigate. However I would like to avoid flashing it since I use it for work too. Has someone ever tried to boot off an external SD card and using just fastboot boot, instead of flashing? I also think X may still require some extra patching to take advantage of HW acceleration, I can check that once the firmware issue is solved. |
|
@Gnurou The cleanest way to do it is to format the system partition (doesn't contain any personal data) and put the Arch Linux Arm files there (rootfs). I'll post my system.img here in a few minutes, so you can try it out. For the kernel, you can try with my latest build (from lightbar-fix branch). This kernel boots from /system/, therefore your /data partition isn't touched at all. KernelThis build assumes you have the rootfs on /system ( Boot w/ RamdiskIn case you want to boot from sdcard / whatever, you'll need to repack the kernel with the new ramdisk. Edit this to suit your needs , repack and you're good to go. System
Flash it w/ Revert back to the original stateTo return to a fully functional Pixel C, download the version you had on your Pixel C, extract the zip file, go to the extracted folder, |
|
Thanks for the instructions, although I'd rather not mess with my work device at all :) I remember booting to a SD card rootfs on my old SHIELD device, let me see if I can reproduce that result on the Pixel C too since USB seems to work. I suppose that kind of setup could be useful to other users as well. Or maybe I can put my hands on another device just for this issue. I will come back once I have results. |
|
You could try adding drm.debug=31 to cmdline for more debugging |
|
@denysvitali also try building as a module |
|
It indeed looks like the firmware files are not present on the initramfs, which would explain why the firmware loading function returns -ENOENT. Building Nouveau as a module should definitely do the trick. An alternative would be to include the firmware files directly within the kernel image using CONFIG_EXTRA_FIRMWARE, but that's definitely not clean. I see no reason to not built Nouveau as a module since nobody should need it until the root FS is mounted anway. |
|
It works indeed. I've selected nouveau as a module, added It is still laggy with GNOME and videos are choppy, but it seems to be accelerated 👍 Thank you! |
|
Oh wow, that's fantastic! Try setting the GPU clock to a higher speed, performance should increase: ... or something like that. cat pstate to see which values are acceptable. Is this X? I would be surprised if it works out-of-the-box, last time I checked it (and Mesa) required a few external patches to connect the display and render nodes together. But maybe this has been taken care of in the meantime. |
|
@Gnurou Yes, it is X. Although GNOME runs on Wayland.
Here is the tree output of I can't figure out why after some minutes I get the green bars (#1) either. Tree of
|
|
I tried the |
|
Cause those patches haven't been pulled/mainlined yet. |
|
Sorry, my mistake. The pstate node has been moved to from sysfs to debugs. So you should be able to find it under /sys/kernel/debug or wherever debugfs is mounted. Still I am not convinced that X is using acceleration at the moment. You may want to check by looking for mentions of glamor the in X logs, or running glxgears or some other GL-enabled application. My bet is that some patching is still needed. |
|
@vartom Good! We can try to |
|
Yesterday I did not manage to make the package. |
|
Unfortunately mesa-18 hasn't been tagged... yet. Let's wait for a release and see if it works. |
|
@denysvitali this is not so important, in 18.0 there is still no support for tegra. |
|
I can not find a solution to several errors. |
|
Hi guys, i just wanted to know if one can use the tegra X1 linux driver https://developer.nvidia.com/embedded/dlc/l4t-jetson-tx1-driver-package-28-2-ga on pixel C. Thank you. |
|
@rakhenmanoa As far as I know this driver can be used only with the appropriate kernel 28.2 (the driver in the kernel) for L4T from nvidia. |
|
Does the recently tagged mesa 18.1 RC support tegra? |
|
yes, it appears to: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/tegra?h=mesa-18.1.0-rc1 as opposed to 18.0.1, which doesn't have the driver: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers?h=mesa-18.0.1 |
|
I'll try a new build tomorrow and report back the results 👍 |
|
Hi guys, the group fail0verflow posted a Linux system for the Nintendo switch with accelerated graphics, there https://fail0verflow.com/blog/2018/shofel2/ Do you think it will work on Pixel C ? |
|
Hey @rakhenmanoa! I noticed it too and I'm currently setting up the CI to generate a rootfs w/ the latest mesa, as suggested by @q66. I'll report back soon: meanwhile you can check the build status here |
|
@denysvitali btw, once the GPU stuff is confirmed working and Mesa 18.1 makes it into its package repository, I'll probably look into porting Void Linux arm64 onto my Pixel C (it frequently lies unused unless I'm traveling, I'd like to change that) - what's the current status of Bluetooth support? Still the same with latest 4.17-rc2 kernel as previously, i.e. not working? Additionally, is there any public discussion channel? (ideally on IRC) |
|
@q66 The current bluetooth support is being tracked in #10. At the moment the brcm4354 works just for the Wi-Fi (= Standard Bluetooth and BTLE doesn't work). I haven't tried the latest 4.17-rc2 kernel, but I'm planning to. Theoretically speaking a kernel build is already ready (but not yet tested) here (and yes, that release name is ugly. I need to fix my CI) There is currently no public discussion channel, but I've just created a Telegram group which can be found here In the following hours I'll test the new kernel, and try to fix my CI. I'll then generate a better rootfs w/ the newest mesa 18.1 Hopefully I'll find some time to migrate / imolement the CI on the pixelc-linux organization. |
|
Alright. I created a |
|
Everyone is welcome to join the #tegra channel on Freenode. Its focus is on upstream Linux development and most people involved with upstream Linux development on Tegra hang out there, so I it should be a good fit for what you're trying to achieve. |
|
Btw, we now have a Telegram group which is linked to the We'll eventually migrate to @pixelc-linux in the near future, in the meantime we'll keep the discussions here, on Telegram and on Freenode. @thierryreding Thanks! I'll make sure to check out the |
|
The kernel 4.17-rc2 does not correctly display the image on the screen. |
|
@vartom What do you mean by "does not correctly display the image on the screen"? Are there glitches? |
|
the logs are displayed correctly. The problem manifests itself when the image forms a GPU. turn on the utility kmscube or take my rootfs with working acceleration. |
|
@denysvitali I do not understand your persistence in using Google blobs. They will not work with the mainline kernel. Using them you will not get hardware video acceleration! ps Conducted an elementary comparison of files by content. In the directory nvidia / tegra210 all files that are used by the mainline kernel (from Linux-firmware) are the same as those from Google. Perhaps the mainline kernel can use old blob names, or maybe not. |
|
This is the email that @vartom has wrote you today. I pasted it here with his permission in order to keep the discussion public, so that everyone can help / be helped.
|
|
This is what happens: |
|
Hello denysvitli, |
|
You will have to wait until our infra is properly up, I guess. Which hopefully shouldn't take long at this point... |
|
Ok cool, im currently actually installing the available build of linux for the pixel c but i ran in to a problem, the cache partition isn't big enough to store the latest rootfs tar |
|
@PixelCUser Just copy the rootfs over Btw, please, let's not go off topic here. If you're having some troubles installing a Linux Distro on your Pixel C, feel free to open a new issue. This is specifically related to the graphic acceleration issues we're facing. In a couple of days we'll probably have a better way to deliver updated versions of our rootfs and kernel images, so that it will be easier for everyone to install a Linux Distro on their Pixel C. Edit: Fix Telegram Link, thanks @mirh |
This reverts commit 4ae4b5c. as per denysvitali/linux-on-pixel-c#2
This reverts commit 4ae4b5c. Why: denysvitali/linux-on-pixel-c#2 (comment)
This reverts commit 4ae4b5c. Why: denysvitali/linux-on-pixel-c#2 (comment)
Currently Linux on Pixel C is missing GPU Acceleration, therefore the UI is laggy
dmesg is available here
The text was updated successfully, but these errors were encountered: