+- RPCS3 Forums (https://forums.rpcs3.net)
+-- Forum: Support & Issues (https://forums.rpcs3.net/forumdisplay.php?fid=17)
+--- Forum: Support (https://forums.rpcs3.net/forumdisplay.php?fid=18)
+--- Thread: Vulkan errors report (/showthread.php?tid=174359)
RE: Vulkan errors report - Yagami Light9 - 03-12-2016
Try it https://ci.appveyor.com/project/rpcs3/rpcs3/build/1.0.1766
RE: Vulkan errors report - Ekaseo - 03-12-2016
vulkan works now for me, idk about the others though
RE: Vulkan errors report - cuzudo - 03-13-2016
(03-12-2016, 11:42 PM)Ekaseo Wrote: vulkan works now for me, idk about the others thoughyeah it's working now
RE: Vulkan errors report - vlj - 03-16-2016
On my GeForce linear tiling prevents texture from using several mipmap level which break almost all 3d games. For some reasons it looks like not all GeForce are affected.
In addition the current implementation always use host visible memory to store data. On Radeon this is fine since device memory is host accessible however on GeForce it's not which means all rendering operation happen in main memory instead of device memory which is bad for performance.
I guess these limitations lead to the upload/default/read back design decision of dx12 ; I'm currently implementing a similar way of doing for Vulkan. While it will add an extra copy operation for Radeon user the texture cache will limit the amount of such copy. On the other hand usage of optimal tiling will increase bandwidth usage for sampling and rendering operation so the benefit are likely to outweighs the drawback performance wise.
If necessary an heuristic could detect which textures are modified per frame and use linear tiling for such texture on Radeon but that's a more long-term idea.
RE: Vulkan errors report - kd-11 - 03-16-2016
(03-16-2016, 01:35 AM)vlj Wrote: On my GeForce linear tiling prevents texture from using several mipmap level which break almost all 3d games. For some reasons it looks like not all GeForce are affected.
In addition the current implementation always use host visible memory to store data. On Radeon this is fine since device memory is host accessible however on GeForce it's not which means all rendering operation happen in main memory instead of device memory which is bad for performance.
I guess these limitations lead to the upload/default/read back design decision of dx12 ; I'm currently implementing a similar way of doing for Vulkan. While it will add an extra copy operation for Radeon user the texture cache will limit the amount of such copy. On the other hand usage of optimal tiling will increase bandwidth usage for sampling and rendering operation so the benefit are likely to outweighs the drawback performance wise.
If necessary an heuristic could detect which textures are modified per frame and use linear tiling for such texture on Radeon but that's a more long-term idea.
I think you could create a staging branch for this so that we can check the impact this will have on radeons. The current texturing implementation on vulkan falls back to staging textures if linear tiling support is not natively available. Is that not working? Or is it too slow?
RE: Vulkan errors report - vlj - 03-16-2016
It's not working atm. Actually the issue is that linear tiling is supported for sampled image, but such image must have only one mipmap level.
Current code only check for linear supports but doesn't check that it can support enough mipmap levels
RE: Vulkan errors report - AlexVS - 03-16-2016
Hi All.
I try run any game with Vulkan api and emulator stop working. With OpenGL api all OK.
Spec: Intel i3, gtx 750ti, 8Gb ram. Graphics Driver 364.51 (with Vulkan support)
Error rpcs3 with Vulkan:
[Image: C2A86DE9-0030-EF24-60BC-35899C33800B.jpg]
RE: Vulkan errors report - Ani - 03-16-2016
(03-16-2016, 06:33 PM)AlexVS Wrote: Hi All.
I try run any game with Vulkan api and emulator stop working. With OpenGL api all OK.
Spec: Intel i3, gtx 750ti, 8Gb ram. Graphics Driver 364.51 (with Vulkan support)
Error rpcs3 with Vulkan:
[Image: C2A86DE9-0030-EF24-60BC-35899C33800B.jpg]
I've found the issue for this and fixed it.
Submitted a PR: https://github.com/RPCS3/rpcs3/pull/1585
RE: Vulkan errors report - AlexVS - 03-16-2016
(03-16-2016, 07:44 PM)Annie Wrote: I've found the issue for this and fixed it.Thanks
Submitted a PR: https://github.com/RPCS3/rpcs3/pull/1585
RE: Vulkan errors report - kd-11 - 03-17-2016
(03-16-2016, 04:46 PM)vlj Wrote: It's not working atm. Actually the issue is that linear tiling is supported for sampled image, but such image must have only one mipmap level.
Current code only check for linear supports but doesn't check that it can support enough mipmap levels
Is there a case where we use textures that aren't sampleable? I didnt know about the sampleable images only having one mipmap level. That sounds very odd considering mipmapping is only really needed for sampling purposes. Driver bug maybe?
EDIT: I noticed in the spec linear tiling allows the driver to set a maxmiplevels of 1. I missed it the first time. In this case i'm guessing we have to copy image to every mipmap level individually.