From: Zack R. <za...@tu...> - 2008-09-28 21:21:23
|
On Sunday 28 September 2008 15:04:42 Stephane Marchesin wrote: > > Oh, I'm thinking about doing driver-specific llvm backends here. Yea, that was always my plan. > I've realised that the difference between GPUs really didn't allow common > intermediate representation. Furthermore, the llvm tablegen format is > very powerful and I don't think it'll be much more work. > > So basically instead of doing > TGSI -> LLVM -> TGSI -> driver The only scenario for this was D3D9 for which the driver has to live in the Windows kernel, and getting LLVM running in a Windows kernel would be excidingly difficult. So the use-case was client-side library does the conversion to LLVM, runs the LLVM optimization passes, transforms back into TGSI and feeds the optimized TGSI to the driver. > I think we should be doing > TGSI -> LLVM -> driver Yea, for all cases where you can get LLVM code-generator into the actual driver that's what we want. > That way we'd allow things like support for both vector (r300, > nv30/40, sse...) backends and scalar (nv50, x87 ...) backends. > Otherwise the scalar backends have to lower the vectors into scalars > at the last minute and this could be suboptimal. I also want to > support fixed pipe that way, by describing the fixed pipe > functionality in llvm DAGs and letting the DAG matcher from llvm do > the actual work. This is a cleaner approach to fixed pipe in gallium > than what I tried before. Sounds wonderful. z |