BeagleV-Ahead - Toolchain on Yocto?

BeagleV
21

I posted earlier today regarding the gpu on the BeagleV.

Before we even consider testing it I need to see some code that lights it up. Have not gotten a reply regarding if the gpu / npu requires a license or not.

Did find some work on rev eng. the vivante but that was pretty stale and for the 6UL, kinda doubt that will work in the Imx8 or the V board since the 6UL is 32 bit.

That pixel format might be the default value if it is not being set in udev or ?? on start up. Here is a guess, maybe assign it a value upon start up. But what value???

22

Could you post the weston.socket that goes with that? Where did that work, on RevyOS?

23 
# cat ./lib/systemd/system/weston.socket
[Unit]
Description=Weston socket
RequiresMountsFor=/run

[Socket]
ListenStream=/run/wayland-0
SocketMode=0775
SocketUser=weston
SocketGroup=wayland
RemoveOnStop=yes

[Install]
WantedBy=sockets.target

yocto, imx8.

That should be independent of the platform, to some degree. Don’t have a V board or I would be using it.

24

I adjusted those units to use my own user/group. The result is the same. I also tried my weston@.service with the root user, just in case it was a permissions issue, but still the same.

This may be the end of the road.

What’s “imx8”?

25

If you found out the pixel format that is being used you might be up and running. Highly suspect what you are getting is a default setting that is " general use".

Maybe @RobertCNelson can jump in on this since the information needed might have to come from the board maker.

26

I think I misunderstood what you were asking there. The format number that shows up in the log is controlled by Weston. For instance, if I use gbm-format=bgrx8888 in weston.ini, I get this:

Apr 03 09:23:20 ahead weston[1016]: [09:23:20.168] format 0x34325842 not supported by output HDMI-A-1

Here’s some output from Sway:

Apr 03 09:25:14 ahead sway[1104]: 00:00:00.099 [ERROR] [wlr] [EGL] command: eglQueryDeviceStringEXT, error: EGL_BAD_PARAMETER (0x300c), message: "eglQueryDeviceStringEXT"
Apr 03 09:25:14 ahead sway[1104]: 00:00:00.099 [ERROR] [wlr] [EGL] command: eglQueryDeviceStringEXT, error: EGL_BAD_PARAMETER (0x300c), message: "eglQueryDeviceStringEXT"
Apr 03 09:25:14 ahead sway[1104]: 00:00:00.156 [ERROR] [wlr] [render/gles2/renderer.c:754] GL_EXT_unpack_subimage not supported
Apr 03 09:25:14 ahead sway[1104]: 00:00:00.156 [ERROR] [wlr] [render/gles2/renderer.c:704] Failed to create GLES2 renderer
Apr 03 09:25:15 ahead sway[1118]: 2024-04-03 09:25:15 - [main.c:293] Found config * for output HDMI-A-1 (Hewlett Packard HP 22cwa 6CM6031XZ0)
Apr 03 09:25:15 ahead sway[1136]: (WW) Option "-listen" for file descriptors is deprecated
Apr 03 09:25:15 ahead sway[1136]: Please use "-listenfd" instead.
Apr 03 09:25:15 ahead sway[1136]: (WW) Option "-listen" for file descriptors is deprecated
Apr 03 09:25:15 ahead sway[1136]: Please use "-listenfd" instead.
Apr 03 09:25:15 ahead sway[1136]: libEGL warning: DRI2: failed to create dri screen
Apr 03 09:25:15 ahead sway[1151]: i3status: trying to auto-detect output_format setting
Apr 03 09:25:15 ahead sway[1151]: i3status: auto-detection: parent process is "sh", looking at its parent
Apr 03 09:25:15 ahead sway[1151]: i3status: auto-detected "i3bar"
Apr 03 09:25:15 ahead sway[1136]: libEGL warning: DRI2: failed to create dri screen

My theory is that the driver in RevyOS doesn’t support eglQueryDeviceStringEXT, and Wayland refuses to use GPU acceleration if it can’t use that to verify that the monitor can handle the requested format.

27

Might very well be the problem.
My self I would find a different board unless you can get by with a Nextion HMI on the UART. If you had all the facts along with a TRM for the SoC it would be much easier to find a problem. Stumbling around totally blind is BS, an end user regardless of their skill level at getting a board running should not be subjected to that. If it cannot handle getting the weston compositor up out of the box it is going to have plenty of problems.

28

Well, I am getting by with Sway. You can definitely notice the software rendering but it isn’t getting in my way so far. The BeagleV-Ahead will be my “playing around with RISC-V” board for now. I wonder how long it’ll be before we get Pi-class boards with RVV 1.0 and supported video hardware?

Thanks for expending so much effort on this.

29

Might be a LONG time, big tech has been doing a good job at suppressing others and closing doors of opportunity. If you look all the companies that have access to the GPU and NPU on the boards it becomes obvious.

These boards are an extreme threat and they know it, so they suppress and manipulate to retain market position.

Can you imagine if a small company is awarded a contract from a fortune 100 player… and beat out a one of the big players in this space…

30

GPU acceleration does work in RevyOS – until you do “apt upgrade”! glmark2-es2 gives a score of 675 (vs a score of 1 with software rendering). It’s not enough to make Weston happy, though.

31

Wayland in general doesn’t seem to benefit from GPU acceleration in un-upgraded RevyOS. Here’s a bit from Sway’s log (with extra logging turned on):

00:00:00.131 [INFO] [wlr] [render/gles2/renderer.c:737] Creating GLES2 renderer
00:00:00.131 [INFO] [wlr] [render/gles2/renderer.c:738] Using OpenGL ES 3.2 build 1.17@6210866
00:00:00.131 [INFO] [wlr] [render/gles2/renderer.c:739] GL vendor: Imagination Technologies
00:00:00.131 [INFO] [wlr] [render/gles2/renderer.c:740] GL renderer: PowerVR B-Series BXM-4-64
00:00:00.131 [INFO] [wlr] [render/gles2/renderer.c:741] Supported GLES2 extensions: GL_ANDROID_extension_pack_es31a GL_APPLE_texture_format_BGRA8888 GL_EXT_blend_minmax GL_EXT_buffer_storage GL_EXT_clip_control GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_conservative_depth GL_EXT_copy_image GL_EXT_discard_framebuffer GL_EXT_draw_buffers GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_EGL_image_array GL_EXT_float_blend GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_gpu_shader5 GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_multi_draw_arrays GL_EXT_multisampled_render_to_texture GL_EXT_multisampled_render_to_texture2 GL_EXT_occlusion_query_boolean GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch GL_EXT_shader_group_vote GL_EXT_shader_implicit_conversions GL_EXT_shader_io_blocks GL_EXT_shader_non_constant_global_initializers GL_EXT_shader_pixel_local_storage GL_EXT_shader_pixel_local_storage2 GL_EXT_shader_texture_lod GL_EXT_shadow_samplers GL_EXT_sparse_texture GL_EXT_sRGB_write_control GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_EXT_texture_format_BGRA8888 GL_EXT_texture_format_sRGB_override GL_EXT_texture_rg GL_EXT_texture_shadow_lod GL_EXT_texture_sRGB_decode GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_RG8 GL_EXT_YUV_target GL_IMG_framebuffer_downsample GL_IMG_multisampled_render_to_texture GL_IMG_program_binary GL_IMG_read_format GL_IMG_shader_binary GL_IMG_texture_format_BGRA8888 GL_IMG_texture_npot GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth_texture GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync GL_OES_element_index_uint GL_OES_fragment_precision_high GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_get_program_binary GL_OES_gpu_shader5 GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_required_internalformat GL_OES_rgb8_rgba8 GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_image_atomic GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_texture_float GL_OES_texture_half_float GL_OES_texture_npot GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_vertex_array_object GL_OES_vertex_half_float GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture
00:00:00.131 [ERROR] [wlr] [render/gles2/renderer.c:754] GL_EXT_unpack_subimage not supported
00:00:00.131 [ERROR] [wlr] [render/gles2/renderer.c:704] Failed to create GLES2 renderer
00:00:00.135 [DEBUG] [wlr] [render/wlr_renderer.c:303] Failed to create GLES2 renderer
00:00:00.135 [INFO] [wlr] [render/pixman/renderer.c:521] Creating pixman renderer
32

Yes, that is turning into a huge pile of BS. Myself, I am getting tired of dealing with wayland and all the cloak and dagger nonsense with it. Did not realize how important the xserver working on a remote GUI is until recently, wayland ripped that out… ARM and wayland are not the best solution for me. Only ones that actually notice the power of the compositor are the developers, end user cannot tell the difference.

I posted some vulkan test code in a post about the new AI-Y board, if you don’t mind would you please try that out and see if you can render a triangle on your V board.

33

Your triangle code fails: it shows a window, says “test”, then “failed to open file!”. No doubt that’s because I don’t have either of those shader files… That’s under X11 (i3), of course it doesn’t get that far under Wayland (Sway).

I’ve written some Wayland client code recently… it’s not for developers either. There are more hoops to jump through to write a Wayland app than either Xlib or XCB. I guess you mean that only the developers of Wayland itself can really “appreciate” it. But I’m making my peace with Wayland. They’ve made some unfathomably idiotic mistakes, like client-side window decorations. But things like that are getting fixed… albeit very slowly. Still, it’d be nice if the proposed replacement for X11 was actually better than X11, not just different.

I wish I could understand what Arcan is up to…

1 Like
34

Yes, I have had my fill of it too. When you run fullscreen and no internet connection no need for all the BS. To get it to run remotely and finding all the hiding spots for setttings, better keep my mouth shut on that.

Thank you for trying that out, please let me know if you have any luck at getting a board up on vulkan.

Might check your env
DISPLAY=:0
WAYLAND_DISPLAY=/run/wayland-0
or
WAYLAND_DISPLAY=wayland-0

35

My environment’s fine, I think, you just didn’t supply “shaders/vert.spv” and “shaders/frag.spv”.

36

You might be right on that, I am away from that workstation with that code. Here is another one that will spawn a blank window and does not require shaders.

cmake_minimum_required(VERSION 3.20)
project(vulkan1)

set(CMAKE_CXX_STANDARD 17)

add_executable(vulkan1 main.cpp)
target_link_libraries(${PROJECT_NAME} glfw vulkan dl pthread X11 Xrandr Xi)

#define GLFW_INCLUDE_VULKAN
#include <GLFW/glfw3.h>

#define GLM_FORCE_RADIANS
#define GLM_FORCE_DEPTH_ZERO_TO_ONE
#include <glm/vec4.hpp>
#include <glm/mat4x4.hpp>
#include <vulkan/vulkan.h>



#include <iostream>
#include <stdexcept>
#include <cstdlib>


//set path environment: DISPLAY = :0
//Run configuration: Emulate terminal in output console





int main() {

    //Verify environment is properly configured either x or wayland
    int status = system("echo \"WAYLAND_DISPLAY=\" $WAYLAND_DISPLAY \n echo \"DISPLAY=\" $DISPLAY"); // Replace "ls -l" with your desired Bash command
    if (status == -1) {
        // Handle error
    }

    //initialize glfw
    glfwInit();
    glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
    GLFWwindow* window = glfwCreateWindow(800,450, "Vulkan Window", nullptr, nullptr);

    uint32_t extensionCount = 0;
    vkEnumerateInstanceExtensionProperties(nullptr, &extensionCount, nullptr);
    //
    std::cout << extensionCount << "extensions supported\n";

    glm::mat4 matrix;
    glm::vec4 vec;
    auto test =matrix * vec;
    GLuint VertexArrayID;
   
    while (!glfwWindowShouldClose(window)) {
        glfwPollEvents();
    }
    glfwDestroyWindow(window);
    glfwTerminate();

    return 0;
}

In the console it will tell you how many extensions are supported if vulkan runs.

37

“20extensions supported”

It runs in Wayland too, but doesn’t seem to actually create a new window there.

38

That is a start, I am going to look into what that extension function is querying and try to find out if that is just looking for files that are present or it actually tries the GPU?

Have had that same experience on Intel x86 with the on board video so it may or may not be GPU related. With a compatible GPU it does work.

Are you able to get a anything back using

$vulkaninfo
39

Yes, too much to quote here.

In Wayland, it says “vulkan: No DRI3 support detected - required for presentation” several times, along with other warnings, notes, and errors. But it does seem to know something about the hardware.

In X11, it prints two warnings about versions from a “loader”, but that’s it for warnings etc.

Is there anything in particular you want to know from its copious output?

40

No, from what I am seeing much of this is a dead end.

It must be the the GPU will not handle vulkan, big tech politics will keep the small companies locked out… I have been working on a different system design that is x86 centric so we can utilize the GPU. One positive note is the bigger the box the bigger the price tag, its hard sell to a customer an expensive product that fits in the palm of your hand.

So its time to make Lemonade from lemons…