vkd3d - DXIL support progress?
Hans-Kristian Arntzen
post at arntzen-software.no
Fri Oct 18 10:05:41 CDT 2019
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 at gmail.com
> <mailto:hverbeet at gmail.com>> wrote:
>
> On Fri, 18 Oct 2019 at 18:08, Hans-Kristian Arntzen
> <post at arntzen-software.no <mailto:post at 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 at arntzen-software.no <mailto:post at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20191018/e9e5fcd5/attachment.htm>
More information about the wine-devel
mailing list