Not really difficult. Haiku BView output should be added here: wsi · master · Mesa / vulkan-wsi-layer · GitLab.
2 Likes
so I’m understanding where this is at.
vulkan api to gpu IR to memory manager to on screen render ?
or is this all just the software renderer ?
This is software lavapipe renderer. Hardware GPU renderer need kernel driver part from Linux kernel sources that is not ported yet, here is WIP port attempt by andreasdr.
When GPU rendering will be available, GPU memory can be copied to BBitmap in RAM and displayed in usual Haiku way. This can be done as initial step before DRM modesetting and compositor will be implemented.
4 Likes
I’d be very curious if the linux driver is worth porting as a whole unit. ???
does valve publish there driver or are the using public or private drivers ???
either way, great progress, certainly laying the ground work.
years ago before my life went crazy, i was learning about the 3d hardware , c++ etc.
I’d say working on using the GPU 2d accelerated drawing functions would be a good start, basically everything i was reading was saying to push everything to the video output buffer ram,
so push drawing data, shaders etc to sys ram, gpu picks up from allocated block area, from that point forward, no data outside od latebcy frame info should move back to sts/cpu ram.
basically open ended, i remember linux had some junk for headless rensering where it complicated the ring bus heavily for these unneeded use cases for desktop.
atombios is involved in this process for 2d and 3d drivers to setup clocks, allocate memory etc
More complex demos are also working:
23 Likes
if you haven’t, you may want to look at the docs here, if you’re thinking about hardware acceleration next
It still need Linux kernel AMDGPU driver.
1 Like
libdrm_amdgpu, i have not looked through all of this as of yet, so you might be way ahead of me here.
this driver is mostly os agnostic
Only its userland part if I am correct. Kernel part is Linux-specific.
libdrm_amdgpu relys on posix ioctls and was created specifically to decouple from hard linux dependency as i understand it, they’d probably upstream haiku specific patches more easily.
This is a list of functions imported from libdrm:
amdgpu_bo_alloc
amdgpu_bo_cpu_map
amdgpu_bo_cpu_unmap
amdgpu_bo_export
amdgpu_bo_free
amdgpu_bo_import
amdgpu_bo_list_create_raw
amdgpu_bo_list_destroy_raw
amdgpu_bo_query_info
amdgpu_bo_set_metadata
amdgpu_bo_va_op
amdgpu_bo_va_op_raw
amdgpu_create_bo_from_user_mem
amdgpu_cs_chunk_fence_info_to_data
amdgpu_cs_chunk_fence_to_dep
amdgpu_cs_create_syncobj
amdgpu_cs_create_syncobj2
amdgpu_cs_ctx_create2
amdgpu_cs_ctx_free
amdgpu_cs_destroy_syncobj
amdgpu_cs_export_syncobj
amdgpu_cs_import_syncobj
amdgpu_cs_query_fence_status
amdgpu_cs_submit_raw2
amdgpu_cs_syncobj_export_sync_file
amdgpu_cs_syncobj_import_sync_file
amdgpu_cs_syncobj_query
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
amdgpu_cs_syncobj_timeline_signal
amdgpu_cs_syncobj_timeline_wait
amdgpu_cs_syncobj_transfer
amdgpu_cs_syncobj_wait
amdgpu_cs_wait_fences
amdgpu_device_deinitialize
amdgpu_device_initialize
amdgpu_get_marketing_name
amdgpu_query_buffer_size_alignment
amdgpu_query_firmware_version
amdgpu_query_gds_info
amdgpu_query_gpu_info
amdgpu_query_heap_info
amdgpu_query_hw_ip_info
amdgpu_query_info
amdgpu_query_sensor_info
amdgpu_query_sw_info
amdgpu_read_mm_registers
amdgpu_va_range_alloc
amdgpu_va_range_free
drmCommandWrite // DRM_AMDGPU_INFO
drmFreeDevice
drmFreeDevices
drmFreeVersion
drmGetCap
drmGetDevice2
drmGetDevices2
drmGetVersion
2 Likes
You’re more than welcome to donate hardware to Haiku Inc., just contact them using the details on this page:
https://www.haiku-inc.org/contact
i don’t have enough knowledge of uni posix linux kernel interfaces to really know where those all go. it looks like a lot of work for sure.
John Bridgman is/was involved with the open source driver team at AMD, he posts on phoronix.com
he could probably get a engineer to help etc.
i wish i had 10% of your skills, I’d be in there getting dirty.
the point I was trying to make was that we don’t need to bring all of the mesa open source driver stack mess to haiku.
2 Likes
It will not help me to make any progress.
1 Like
Yeah, I wasn’t sure if you needed any hardware or not so I just linked to the Haiku Inc page on that - if hardware is donated to Haiku Inc other developers can use it too.
1 Like
I already have Vulkan compatible Radeon and Intel graphics cards so no attitional hardware is needed for now.
7 Likes
Current hardware baseline (Mesa 21.2.2/Vulkan 1.2.193/Haiku R1B3):
- Vulkan 1.2.193 conformant 3D hardware
Legacy baseline hardware reference (Vulkan 1.0/Haiku R1B3):
- AMD Radeon HD 2000 series - Y2007
- Intel HD Graphics (Gen 7) series - Y2012
- Nvidia Geforce 8000 series - Y2006
Baseline 3D applications supportable on Haiku:
- Blender 2.93.4
- Drag[en]gine 1.6
- Godot 3.3.3
4 Likes
With some hacks window output is added. Proper support will need adding Haiku-specific Vulkan extensions for surface and swapchain.
40 Likes
Can’t wait to see the frames sooner or later go to the moon. 
You are indisputably one of those developers who makes reading this forum an entertainment.
13 Likes
Glfw3 is what most Vulkan samples/tutorials use (over 90%), including my cross platform engine, so I guess a combo of lavapipe/glfw3 is needed for most tutorials on the net to work with a simple recompilation and no code changes. That would be amazing to have. Glfw3 supports Vulkan and can have a count of BBitmaps attached to a BView for Haiku integration.