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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
