Summary: | [anv] vulkaninfo > Haswell Vulkan support is incomplete | ||
---|---|---|---|
Product: | Mesa | Reporter: | Darius Spitznagel <d.spitznagel> |
Component: | Drivers/Vulkan/intel | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Status: | RESOLVED INVALID | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | high.entropy, jason, ryao |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set,Reset}Event on gen7 |
Description
Darius Spitznagel
2018-02-23 11:43:32 UTC
My understanding is that HSW is lacking hardware features. (In reply to Mark Janes from comment #1) > My understanding is that HSW is lacking hardware features. That's not quite true. I believe Haswell is capable of doing everything required for Vulkan but there are some corner cases it doesn't quite handle right. In particular: 1) Haswell doesn't support stencil texturing 2) Haswell border colors are bizarrely format-dependent and some sort of shader work-around would be neede for them to work correctly. 3) vkCmdWaitEvents is not implemented because Haswell lacks a memory-based MI_SEMAPHORE_WAIT. This could probably be worked around by doing a busy-loop in the command streamer. On Ivybridge and Bay Trail, there are a couple other issues: 4) No support for texture swizzle so channel orderings just don't work. 5) Integer border color basically doesn't work at all. The only fix is very painful shader workarounds. That's all I know of off-hnand and it's probably all fixable. However, we (Intel) have no commitment to Vulkan on Haswell hardware and earlier beyond trying to avoid breaking it further. If some community member wants to take on an item on that TODO list, I'd be happy to review and help land the patches but they're all fairly annoying things to fix. (I've already fixed all the easy stuff.) The DXVK pointed out that Haswell lacks bounds depth support. Which item would that be? I meant DXVK developer. Sorry for the typo. Created attachment 144483 [details] [review] [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set,Reset}Event on gen7 This might be enough to DXVK going again on gen7. But I was too lazy to test it myself. (In reply to Ville Syrjala from comment #5) > Created attachment 144483 [details] [review] [review] > [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set,Reset}Event on gen7 > > This might be enough to DXVK going again on gen7. But I was too lazy to test > it myself. I think we need MI_SEMAPHORE_WAIT too in vkCmdWaitEvents. (In reply to Lionel Landwerlin from comment #6) > (In reply to Ville Syrjala from comment #5) > > Created attachment 144483 [details] [review] [review] [review] > > [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set,Reset}Event on gen7 > > > > This might be enough to DXVK going again on gen7. But I was too lazy to test > > it myself. > > I think we need MI_SEMAPHORE_WAIT too in vkCmdWaitEvents. I didn't see that used in dxvk code. Also we don't have it on gen7 so would need something a bit more crazy. Recursive batch with MI_COND_BB_END? Or would there be a better way to achieve this? (In reply to Ville Syrjala from comment #7) > (In reply to Lionel Landwerlin from comment #6) > > (In reply to Ville Syrjala from comment #5) > > > Created attachment 144483 [details] [review] [review] [review] [review] > > > [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set,Reset}Event on gen7 > > > > > > This might be enough to DXVK going again on gen7. But I was too lazy to test > > > it myself. > > > > I think we need MI_SEMAPHORE_WAIT too in vkCmdWaitEvents. > > I didn't see that used in dxvk code. Also we don't have it on gen7 so would > need something a bit more crazy. Recursive batch with MI_COND_BB_END? Or > would there be a better way to achieve this? Yeah I guess this is the way to do it. (In reply to Lionel Landwerlin from comment #8) > (In reply to Ville Syrjala from comment #7) > > (In reply to Lionel Landwerlin from comment #6) > > > (In reply to Ville Syrjala from comment #5) > > > > Created attachment 144483 [details] [review] [review] [review] [review] [review] > > > > [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set,Reset}Event on gen7 > > > > > > > > This might be enough to DXVK going again on gen7. But I was too lazy to test > > > > it myself. > > > > > > I think we need MI_SEMAPHORE_WAIT too in vkCmdWaitEvents. > > > > I didn't see that used in dxvk code. Also we don't have it on gen7 so would > > need something a bit more crazy. Recursive batch with MI_COND_BB_END? Or > > would there be a better way to achieve this? > > Yeah I guess this is the way to do it. I can confirm that that patch is enough to get DXVK going again on gen7. I tried it out on my Iris pro 6200 and was able to run Grandia II with the latest DXVK commit. I think that patch is mostly fine. No sane application actually relies on waiting on a vkSetEvent from the CPU. My only comment is that if we're going to move most of event handling to genX_cmd_buffer.c, we should move all of it and just put the MI_SEMAPHORE_WAIT behind a #if GEN_GEN >= 8 with the anv_finishme() in the #else. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.