VC4 64-bit (f)kms not working #72
Comments
|
Ok so on the latest downstream 4.4 (32) it seems firmwarekms also doesn't work with egl/gl and also freezes after the first frame on Qt. The only error here (for dsi and hdmi) is: This error was also on 4.9 but it seemed insignificant compared to the rest. |
|
I was sort of able to get fkms working on 64 bit on the downstream 4.10 kernel. I'm able to play movies with VLC with software decoding which is something I couldn't do with the basic frame buffer driver. I do see wierd hangs in the GPU from time to time. It seems to be somewhat dependent on the monitor resolution with hangs being more common at higher resolutions. When the RPI hangs, it's still completely accessible through ssh, so I'm rather certain this is either a VC4 driver or GPU issue. |
|
@Electron752 as I think I have already said, my fkms does "seem" to work on 4.10 (and from what I can tell to the same extent on 4.9) in that it brings up the graphical framebuffer and does not crash at bootup with no dmesg errors. This is not the case with plain kms though which just not want to work on 64 bit (black screen & loads of errors...). I have not checked any VLC decoding as I do not need that. My concern is with rendering OpenGL ES 2 graphics and that does not seem to want to work. As described in #78 though this seem to be a general issue with fkms on any architecture and any kernel. Hopefully once that's sorted anywhere it should work here as well. |
|
Sorry, I missed that. Plain KMS also works to some degree on 64 bit with 4.10. The only issue is also the weird GPU resets and lockups. I'm note sure from your post if you compiled Mesa yourself or if you got it from somewhere. One of the requirements is that VC4 support needs to be compiled in and it isn't by default and isn't on most distros. Debian sid arm64 does have it built-in through at this time. |
|
@Electron752 I compiled it myself as part of a 32-bit root filesystem and it does work with plain kms and a 32-bit kernel but it does not work with fkms anywhere. I get the same behaviour when I run the Raspbian rootfs configured to use the VC4 driver through rpi-config which I guess installs the correct mesa. Can you get something like https://github.com/ds-hwang/gbm_es2_demo to run at all with a 64 bit kernel? PS. Compliling a 64 bit rootfs and mesa does not change anything here. |
|
Yep, it works fine with the downstream 4.10 kernel compiled for arm64 on debian sid arm64. I downloaded the source, built it, ran it, and I now see the spinning colored cube on my RPI3 in ARM64 mode! I did have to disable the X windows desktop as I get an access denied when running from X windows. I'm guess this has something to do with it not being built on top of the X windows system and it can't run at the same time as the x windows server. Here is what I have in my config.txt: Here is the output of uname: |
|
Meshlab works quite well from the X windows desktop when running the 64 bit 4.10 kernel as well. Here is the output of glxinfo: OpenGL ES profile version string: OpenGL ES 2.0 Mesa 13.0.3 216 GLX Visuals
|
|
That's great news, I'll see if I can also get it working here like that. Have you had any luck with fkms though? |
|
fkms works as well. I haven't tried it with the demo you sent me through. I'll try it later. I still occasionally see weird hangs in the GPU and CMA allocation issues from time to time, but I'm not sure this is anything 64 bit specific. |
|
OK, I tried the demo with fkms. And guess what... It doesn't work... Just a blank screen. Well, at least regular kms is working. I understand fkms is a short term solution anyway. |
|
Yes I guess it might be a short term solution but it does not really seem to work at all. The reason I would like to have it working is to be able to have a splash screen because in normal kms the driver only kicks in way to late for this. |
|
fkms works for me, and like I said I can play movies on it even though I can't with the standard frame buffer device. It just doesn't work that well:) As for the splash screen, the upstream kernel uses the simplefb driver to display boot info until the kernel is far enough along to load the drm based driver. I've heard that the firmware detects somehow that the VC4 driver is going to be used, and it fakes a simplefb device in the device tree just for that purpose. You can probably make some simple changes somewhere(probably device tree) to make it work on the downstream kernel as well. As for simplefb, you would have to do all the graphics in software through without any hardware acceleration. It is kind of a chicken and egg problem. |
|
Ok I can confirm that kms now works in 4.10 64 bit even though fkms still seems to not really work anywhere. I am therefore closing this issue as there is a separate one to address fkms. |
kvmppc_gpa_to_ua() accesses KVM memory slot array via
srcu_dereference_check() and this produces warnings from RCU like below.
This extends the existing srcu_read_lock/unlock to cover that
kvmppc_gpa_to_ua() as well.
We did not hit this before as this lock is not needed for the realmode
handlers and hash guests would use the realmode path all the time;
however the radix guests are always redirected to the virtual mode
handlers and hence the warning.
[ 68.253798] ./include/linux/kvm_host.h:575 suspicious rcu_dereference_check() usage!
[ 68.253799]
other info that might help us debug this:
[ 68.253802]
rcu_scheduler_active = 2, debug_locks = 1
[ 68.253804] 1 lock held by qemu-system-ppc/6413:
[ 68.253806] #0: (&vcpu->mutex){+.+.}, at: [<c00800000e3c22f4>] vcpu_load+0x3c/0xc0 [kvm]
[ 68.253826]
stack backtrace:
[ 68.253830] CPU: 92 PID: 6413 Comm: qemu-system-ppc Tainted: G W 4.14.0-rc3-00553-g432dcba58e9c-dirty #72
[ 68.253833] Call Trace:
[ 68.253839] [c000000fd3d9f790] [c000000000b7fcc8] dump_stack+0xe8/0x160 (unreliable)
[ 68.253845] [c000000fd3d9f7d0] [c0000000001924c0] lockdep_rcu_suspicious+0x110/0x180
[ 68.253851] [c000000fd3d9f850] [c0000000000e825c] kvmppc_gpa_to_ua+0x26c/0x2b0
[ 68.253858] [c000000fd3d9f8b0] [c00800000e3e1984] kvmppc_h_put_tce+0x12c/0x2a0 [kvm]
Fixes: 121f80b ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO")
Cc: [email protected] # v4.12+
Signed-off-by: Alexey Kardashevskiy <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
I am trying to get the 4.9 downstream kernel to run on VC4 with 64 bit and I am getting very close. I can now compile and run and even the fb console comes up on VC4. My ultimate goal is to use the official DSI display but at the moment I am experiencing the same situation on DSI and HDMI.
I started by porting all the patches related to DSI and when I started getting the issues I just copied the entire VC4 driver from 4.4 directly and changed the few api change related build issues to their 4.9 counterparts in order to get it to build again. This helped a bit (made plain kms work for 32-bit) but did not solve everything.
I want to get Qt5 running with EGLFS on KMS and am currently testing that and the simpler https://github.com/ds-hwang/gbm_es2_demo but they seem to behave the same.
With my 4.9 kernel as it is on https://github.com/Gerharddc/linux/tree/4.9-dsi-yocto I can get everything working on 32 bit with the kms overlay. When I use the fkms overlay though then I get the following errors from the programs after starting them:
No usable crtc/encoder pair for connector "UNKNOWN1"On Qt this means the first frame is rendered and nothing more whilst on the other program nothing renders and the screen is just black.
The situation for fkms on 64-bit is exactly the same. On 64-bit though plain kms does not want to come up and gives the following errors:
I have not yet tested to see if fkms works on 4.4 (32) because I assumed it works. I will be testing it soon though just to make sure.
Assuming fkms works on 4.4, could there be something outside the VC4 codebase (because I basically ported all of it) causing fkms not to work on 4.9? Also, could there be something 64-bit related causing normal kms to fail even though vc4 compiles just fine for the architecture?
I know 64-bit isn't officially supported but if someone can give me a hint of where I should be looking to solve this issue other than the vc4 folder then I can try to figure it out myself. I guess fkms being completely broken on 4.9 is a real issue though?
PS. I am on Mesa 13.01 as on the Yocto master branch.
EDIT:
I don't see any dmesg errors when using fkms.
The text was updated successfully, but these errors were encountered: