Vulkan lavapipe software rendering is working on Haiku

Can be also possible, but need more patching libdrm and Vulkan userland drivers (especially Intel).

1 Like

Would reduce need to muck with haiku kernel, and allow for other linux drivers to more easily be ported. Accelerants are cloneable iirc. Just put nerded functions in the ioctls accelerant, like futex

Also at least to get started, acceletants outside kernel gives a layer if protection vfrom kernel being take ln down with a code errors.

If you want a really crazy idea, use hardware virtualization, put the rntire linux kernel in a accelerant, use it as a virtualized slave, sounds difficult as hell, but would guve haiku a low maintenance driver structure to rely on

Just some random things that come to mind here:

  • While I do understand the risks of putting to much functionality in the kerneldriver, I think for some functions we should allow that anyway (futex I read somewhere for instance?), but keep it simple and as much as is possible in the accelerant, even if that means (not too much) creating some special stuff based on the linux kernel variant: as long as it doesn’t take too much work to move that to userspace.

  • I think it’s perfectly OK to extend/modify the accelerant we have: the 2D hooks can be gone I guess, and all acceleration can be done via the 3D route in the end (but should work for more than a single output windows then of course).

  • Using IOcontrols is slow AFAIK which means you want to do it minimally for 3D acceleration.

  • Using 3D acceleration ‘per definition’ (I’d say) means we lose some security. It’s not possible to doublecheck each action being taken since that will be a large speed penalty to the acceleration we’d net have.

  • All the more reason of course to keep error prone stuff in userland.

  • Speaking for myself: I am not that interested in not having it in kernelspace temporary if that means we’d have acceleration in no time. Once that works it can be finetuned later. Just a hack solution at this point I’d find better than no solution at all: since it delivers us knowledge and we’ll quickly find out where risks and bottlenecks are when rearranging it then.

  • I hope I make a bit of sense… As you probably gathered, I’m no architect :wink:

9 Likes

From libdrm sources:

    /* The whole drmOpen thing is a fiasco and we need to find a way
     * back to just using open(2).  For now, however, lets just make
     * things worse with even more ad hoc directory walking code to
     * discover the device file name. */

:man_facepalming:

There are no such things in Haiku as device major/minor number. libdrm need some rework to be actually usable on Haiku.

8 Likes

hehe the funny paradox would be that you go and rewrite an “haiku version of drm” and then the linuxians see it and take it as a starting point to do a more decent rewrite :joy:

8 Likes

I started implementing my own libdrm.so without major/minor and KMS stuff. I implemented some stub graphics card device and drmIoctl() so Radeon Vulkan driver detect stub graphics card and attempt to initalize. Currently it fails because of unknown GPU family ID.

libdrm_amdgpu.so is used without modifications.

> /Haiku/data/packages/Vulkan/build.x86_64/bin/gears
drmGetDevices2()
drmIoctl(3, 0xc0406400)
DRM_IOCTL_VERSION
drmIoctl(3, 0xc0406400)
DRM_IOCTL_VERSION
drmIoctl(3, 0xc0406400)
DRM_IOCTL_VERSION
drmIoctl(3, 0xc0406400)
DRM_IOCTL_VERSION
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_ACCEL_WORKING
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_DEV_INFO
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_READ_MMR_REG
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_READ_MMR_REG
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_READ_MMR_REG
/Haiku/data/packages/libdrm/drm/builddir.x86_64/install/share/libdrm/amdgpu.ids version: 1.0.0
drmGetDevice2()
drmFreeDevice()
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_DEV_INFO
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_UVD
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_UVD
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_UVD
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_UVD
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_VCN
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_VCN
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_VCN
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_VCN
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_UVD
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_VCN
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_FW_VCN
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_VRAM_GTT
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_VRAM_USAGE
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_VRAM_GTT
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_VIS_VRAM_USAGE
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_VRAM_GTT
drmIoctl(4, 0x80206445)
DRM_AMDGPU_INFO
  AMDGPU_INFO_GTT_USAGE
amdgpu: unknown (family_id, chip_external_rev): (0, 0)
drmFreeDevices()
drmFreeDevice()
Fatal : VkResult is "ERROR_INITIALIZATION_FAILED" in ../base/vulkanexamplebase.cpp at line 926
gears: ../base/vulkanexamplebase.cpp:926:bool VulkanExampleBase::initVulkan(): res == VK_SUCCESS
Kill Thread
18 Likes

It’s certainly more complicated than that but if it proves good real Linux people will not trip over their own pride :wink:

2 Likes

The card uses Atonbios “or they used to”, the mode setting driver calls into the atombios, the mode setting driver should have this information already

If you don’t know, atombiis is the gpu bios subsystem,

Radeon video memory structure if I am correct. GPU have its own virtual memory and page table like CPU.

image

9 Likes

That sounds about right. Especially in Vulkan you don’t have the driver do memory management between the two. You can pretty much allocate the entire memory range and do your own memory manager on top of it.

I do believe that is correct. Atombios is called during boot, and bring up gpu 3d accel. kalisti5 should be able to help here.

This seems correct, but IIRC Radeon iGPUs use part of the system RAM as VRAM. Typically by default around 1 GB RAM is carved out for the iGPU and 4 GB RAM for GTT (graphics translation table), however these are dynamic and can be changed on-the-fly.

I made some progress with implementing amdgpu drmIoctl. I also improved drmIoctl decoder that allows to log interaction between Vulkan userland driver and amdgpu. Now it crash because shader buffer is NULL.

I also found a way to avoid mmap call. There is drm_mmap macro in libdrm, I made it redirect to real function drmMmap that internally calls create_area.

I made my own libdrm.so that have no major/minor fd tricks, KMS and most other parts. It is enough for Radeon Vulkan driver. libdrm_amdgpu.so is left unchanged, it provides quite nice abstractions.

15 Likes

For some unknown reason after recompiling Radeon Vulkan driver, shader creation started working and it now attempts to send commands to GPU ring buffer (that is currently not implemented). It currently fails at unimplemented waiting for finished GPU ring buffer commands.

18 Likes

Awesome progress

Very nice, I wish I could help with testing, but I don’t have the means to get a computer with a Radeon GPU at the moment :frowning:

If the RADV port goes far enough to need it, I could help with testing on Polaris (RX 560X), Vega (RX Vega 8), and Navi (RX 5700 XT) GPUs.

Render loop is running. But currently it don’t render anything yet. Most part of interaction with graphics card is not yet implemented.

Major parts needed to be implemented:

  1. Initialization and acquiring information.
  2. Graphics memory allocation (AMDGPU_GEM_CREATE).
  3. GPU virtual memory mapping (AMDGPU_GEM_VA).
  4. Sending command buffers to GPU ring buffers (AMDGPU_CS).
  5. Handling interrupts to know when command execution completed (AMDGPU_WAIT_CS).

Old Linux radeon driver can be used as reference because it is smaller and easier to understand.

23 Likes

Do you mind if i share this post at Phoronix ?

3 Likes

OK to share. Keep in mind that hardware rendering is not actually working yet, many parts are not properly connected to hardware for now.

5 Likes