On Wed, Jan 14, 2015 at 11:06:50AM +0900, Michel Dänzer wrote: > On 14.01.2015 04:07, Tom Stellard wrote: > > On Tue, Jan 13, 2015 at 06:47:00PM +0900, Michel Dänzer wrote: > >> On 07.01.2015 10:10, Michel Dänzer wrote: > >>> On 07.01.2015 06:33, Tom Stellard wrote: > >>>> On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote: > >>>>> On 24.12.2014 02:49, Tom Stellard wrote: > >>>>>> Rather than building a new one every compile. This should reduce some > >>>>>> of the overhead of compiling shaders. > >>>>> > >>>>> Thanks, though unfortunately it doesn't seem to make much difference for > >>>>> piglit for me. > >>>>> > >>>>> > >>>>>> One consequence of this change is that we lose the MachineInstrs dumps > >>>>>> when dumping the shaders via R600_DEBUG. The LLVM IR and assembly is > >>>>>> still dumped, and if you still want to see the MachineInstr dump, you > >>>>>> can run the dumped LLVM IR through llc. > >>>>> > >>>>> Sounds reasonable, but... > >>>>> > >>>>> > >>>>>> @@ -503,5 +510,12 @@ struct pipe_screen *radeonsi_screen_create(struct > >>>>>> radeon_winsys *ws) > >>>>>> /* Create the auxiliary context. This must be done last. */ > >>>>>> sscreen->b.aux_context = > >>>>>> sscreen->b.b.context_create(&sscreen->b.b, NULL); > >>>>>> > >>>>>> + /* Initialize LLVM TargetMachine */ > >>>>>> + r600_target = radeon_llvm_get_r600_target(); > >>>>>> + sscreen->tm = LLVMCreateTargetMachine(r600_target, "r600--", > >>>>>> + > >>>>>> r600_get_llvm_processor_name(sscreen->b.family), > >>>>>> + "+DumpCode", LLVMCodeGenLevelDefault, > >>>>>> LLVMRelocDefault, > >>>>>> + LLVMCodeModelDefault); > >>>>>> + > >>>>>> return &sscreen->b.b; > >>>>>> } > >>>>> > >>>>> ... since you pass "+DumpCode" here, the MachineInstrs are actually > >>>>> always dumped unconditionally. With that fixed, this patch is > >>>>> > >>>> > >>>> I've removed the MF.dump() call in the LLVM tree, so this won't happen. > >>> > >>> That won't help people using LLVM 3.4 (or 3.5?), will it? > >> > >> Tom, users of LLVM 3.4/5 get spammed by MachineInstr dumps with this > >> change, right? Do you have a plan to address this? > >> > > > > I disabled target machine caching for < LLVM 3.6, so this shouldn't be > > an issue. > > I see, thanks for the clarification. > > BTW, do you think it would also be possible to keep around the LLVM > module / context between shader compilations? >
We can cache the context. We could cache the module too, but I'm not sure if there are any advantages to doing that. -Tom > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
