Vulkan lavapipe software rendering is working on Haiku

Correct output is produced when using saveScreenshot() function from screenshot sample. It currenly produce to file, not window. FPS is low because WSI module is doing copy from VRAM to CPU memory by memcpy() that is terribly slow, DMA engine should be used.


Posted by Falkon and QtWebEngine.


Hi, Glad to see you post again :wink:
Please checkout the engine’s stride restrictions on the card, and compare that to the mode stride being set by the haiku driver: it might well be that the haiku driver needs to be updated to take the engine restrictions into account (by adding / modifying the slopspace).

As a intermediate test you can try if another horizontal resolution mode would work correctly. If it does, that’s a hint in this direction.

Congrats on this very important step!

EDIT: also a higher colordepth can help: on some engines the stride granularity is not in pixels, but in bytes…


Graphics card is currently working only for acceleration, display output is not used. Display is connected to embedded Intel GPU. Render output is copied to CPU memory and displayed as regular BBitmap. Vulkan API have ability to convert buffer to linear format and copy it to CPU memory.


Ah, OK. So the software copy to the screen is not the problem if all is right then. Still, the viewport might? But I’d assume that’s set by the same driver as does the 3d accel calcs… Anyhow, you need to copy line by line I’d guess to not be fooled by differences in the granularity at some point in the ‘line’.

Problem is already solved by using Vulkan API to copy video buffer to CPU memory instead of memcpy() that not takes tiling in account.


Still, a screenshot to file does not have slopspace per definition I’d say, while output on some desktop often does have this I think.

What does it mean? “Slopspace”.

slopspace is unused space at the right side of a screen. If your desktop has a resolution that’s not dividable by the engine granularity, such a desktop is created ‘oversized’ (horizontally) to make it possible for the engine, but also for CRTC’s to do their ‘burst’ like accesses.
The DAC output (or these days digital link) does send other timing than the desktop is configured in, so for the user it seems the requested resolution is set, while in fact, it is not.

Different parts of graphics cards have different restrictions:

  • CRTC often (horizontally): 8 pixels, but often more
  • 2D engine
  • 3d engine (could be same engine)
  • backend scaler
  • hardware colorspace converters

The trick is to find the largest granularity for each of the used components and use that to set the mode, otherwise things will fail. (for instance VLC did this wrong long time ago: I had to send a patch especially for nvidia gfx cards since these had a larger granularity than anything they saw before)


@x512: btw: the amount of slopspace set for a mode you can see by comparing the mode’s ‘BytesPerRow’ with the set ‘horizontal resolution * ceil(colordepth div 8)’.


I wish there was an other way than PayPal. I just don’t do PayPal.

1 Like

If you’re okay with donating to the project as a whole, Haiku Inc does accept Liberapay (an alternative to Pay Pal and Patreon), checks and bitcoin as alternative payment methods.
More information here: Please make a tax-deductible gift today. - Haiku, Inc.

1 Like

Wow, any idea about the patt to direct card outout for rendering ??? I see the first step for gpu compute is here .

Awesome progress

I have a regular donation going to Haiku as a whole. I just don’t use PayPal and that means donating directly to x512 for this specific work is… well… I would love to but just can’t. I do however really, apricate him taking on this task.

1 Like

Hmm, @X512, would you be willing to set up a Liberapay account for this case?

That way the people who don’t use PayPal have an alternative platform they can donate via if they choose to directly support you.

More samples are working. Memory copy speed problem is not yet fixed, so ~11 FPS limit.







Is this a issue with dma in the kernel ??

Driver is working fully in userland including DMA and physical memory mapping. Currently existing unmodified radeon_hd kernel driver is used to map MMIO registers and mappable VRAM area.


What are the next steps to get to output from graphics card natively, also kernel lsnd level drivers which are more performanant etc.

Just for those of us following along, wondering what the road map looks like


Perhaps it might be a good idea to split the RADV posts into another topic or renaming the topic title?

Yes, I think that splitting Radeon driver work is a good idea. Maybe from here.