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 
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:
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.
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.
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.
Hmm, @X512, would you be willing to set up a Liberapay account for this case? https://liberapay.com/
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.