18 Oct
2019
18 Oct
'19
3:05 p.m.
On 10/18/19 5:02 PM, Greg Roth wrote:
Just to be clear, the control flow structuring problem is something I have addressed, so work on an algorithm that would solve this problem would not be duplicated effort.
I assume a typo here, there's a contradiction.
Cheers, Hans-Kristian
Greg
On Fri, Oct 18, 2019 at 8:46 AM Henri Verbeet <hverbeet@gmail.com mailto:hverbeet@gmail.com> wrote:
On Fri, 18 Oct 2019 at 18:08, Hans-Kristian Arntzen <post@arntzen-software.no <mailto:post@arntzen-software.no>> wrote: > On 10/18/19 4:32 PM, Henri Verbeet wrote: > > On Fri, 18 Oct 2019 at 17:51, Hans-Kristian Arntzen > > <post@arntzen-software.no <mailto:post@arntzen-software.no>> wrote: > >> Most of the (little) time I've spent so far as been coming up with an algorithm to convert DXIL's unstructured control flow to something which conforms to SPIR-V's structured model. > >> > > I may be missing something, but the existing vkd3d-shader code already > > needs to take care of that > > (vkd3d_dxbc_compiler_emit_control_flow_instruction() in particular), > > since both TPF and the (very thin) vkd3d-shader IR are unstructured as > > well. > > From what I can tell, the DXBC is structured already, and if/endif and > friends are already emitted directly, so there isn't any complex > analysis required to convert it to SPIR-V. DXIL is unstructured, i.e., > it's a goto soup, but it has to be a reducible CFG at least. I didn't > see any implementation for that. > Right, I wouldn't exactly call TPF structured, but it's not quite unstructured either, and doesn't have goto/jump. I wasn't aware that DXIL did. Henri