Did you try to size the window of glxgears. On my VF2, I got correct framerate with Gnome on Xorg only, on wayland (Gnome) the framerate is pure cheese over time. it seems that X11 is still software emulated on VF2 wayland.
If you want to stay up to date here, use this link to search the LKML: @imgtec.com - search results
1 Like
I think the JH7110 GPU should support desktop graphics applications as soon as possible, such as coolpi (RK3588S), whose GPU can run opengl and vulkan programs, while IMG GPU vulkan is not yet adapted
1 Like
i agree with you
1 Like
Only works :
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, w,h);
Wanted :
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH24_STENCIL8, w, h);
1 Like
Maybe you are trying desktop OpenGL instead of GLES.
GL4ES exactly.
Might be a linking issue maybe where you are using gles headers or something
Anyways GL_DEPTH24_STENCIL8 needs to be GL_DEPTH24_STENCIL8_OES on GL ES 2.0.
Please feel free to add your voices to this issue asking for the Open Source GPU drivers to be released.
7 Likes
I’ve added a comment to express my disappointment at the ongoing lack of open GPU drivers.
6 Likes
Me too… But even worse the JH7110 has no DSP so it will never be compatible with the display in the uConsole.
1 Like
I filed a bug with Ubuntu saying the display driver isn’t working or loading within the kernel and u-boot. We’ll see what happens from that.
You can also file one with them on the same issue, more reports of it not working will get more attention.
You can file it with whatever distro you use.
RC
We should be pestering Imagination, instead. I’m kind of fed up with the attitude, to be honest. They got their shiny renewed RV64 reputation now, they should start owning it.
So I was going to run a few tests on the GPU. (For the record, I have no idea what I am doing. Yet.) The plan was to first compile a list of working, GLES-compliant games and applications, then just doing some official PVRTools shenanigans. Nothing special.
I downloaded Imagination’s official SDK, which failed to compile because it reffered to drm/drmfourcc.h, which was actually in libdrm/drmfourcc.h … on ALL my machines. Then it compiled smoothly, resulting in a bunch of (perfectly working) demos, library sources and…no tools. Hey, aren’t PVRTools incuded in this?
Turns out no. No source, just links. Okay, so I’ll download a x86-64 gnu ubuntu version or something, and run it through box64. Nope. Link is dead. All of the links time out.
… oh, so I can get those programs by registering an account. But I bought a RISC-V machine and am the type of a guy that likes to build their system from the ground up as an expression some deep-seated vent of paranoia and social phobia - chances are I don’t want to be in a database somewhere just for the F of it. This is ludicorusly far from open source, let alone free software. The only build-yourself diagnostic PVR tool out there produces an Android build. But I wanna run diagnostics on my free-software inspired risc-v machine!
Set aside the fact Imagination make terrible drivers and tend to leave stuff in the dust. Set aside the fact that they are so criminally under-staffed they can’t even afford to fix their website to exclude links to PVRTools for Ubuntu 12 or update the sources for their software development “kit” (which excludes basic diagnostic tools). The very fact that on their developers’ forum what should be an interesting technical question on framebuffers is muddied into bureaucracy before getting shot down entirely (“whoops our shit doesn’t work. Let me get back to you”) should be an enormous red flag.
Sorry for the rant. Bottom line is, I don’t Ubuntu or even Starfive will be able to help … but maybe they will end up pressuring Imagination enough to actually invest into this, so who knows.
PS nowhere on the product page for starfive 2’s gpu does it say “desktop” …
4 Likes
Oh, the irony. They want to present themselves as the right GPU choice for your RISC-V project. Anyone attending the RISC-V summit October 22-23 Santa Clara, California?
2 Likes
I’ll be there 21-23. Happy to discuss with you, although I’m not hoping too much on the Imagination GPU. I’m curious to see how framework/DeepComputing can even attempt JH7110 with all the GPU craziness. If the GPU driver is not fully open-sourced and upstreamed, which mainstream distro is willing to spend the time following up with this thing? Let alone producing a nice deb/rpm packaging of those closed source drivers.
2 Likes
It is a bad idea to ask developers to release unfinished code. The rumors say it will (probably) happen in 2024. You would not ask to move into a house that they had poured the foundation, put up three walls, had most of the roof in place and no plumbing, electricity and gas. Asking a very small team of developers (from what I have seen) to release unfinished buggy code will just cause even more friction. Leave them alone I’m sure they have targets to meet for bonuses etc. Bsically they are under enough pressure without random people from the internet harassing them.
Nobody is asking them to release unfinished code.
However I know that for IT Organizations priorities are often determined by customer requests. If the customers are not requesting a feature it often goes to the bottom of the priority list.
1 Like
I’d say we are used to unfinished buggy code.
But even when they want to wait for a usable release, there is no need to stay silent.
Compare this with for instance Collabora on the GPU driver for the ARM Rockchip RK3588.
They kept us in the loop. Here are some posts.
February 2023: PanCSF: A new DRM driver for Mali CSF-based GPUs
July 2023: A helping Arm for Panfrost
March 2024: Release the panthor!
2 Likes
There is some good progress. They say that adding new drivers should be “fairly trivial”.
4 Likes
Wouldn’t it be cool if we got kernel/mesa3d support before 2 year anniversary of first boards shipping?
It seems feasible.
3 Likes