<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Fri, Jun 5, 2015 at 1:49 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think so. The LLVM IR generated by radeonsi is slightly different from the one generated by r600g. The most code that can be shared is shared already. Right now the main problem of the R600 LLVM backend is lack of features. I think it's approximately at the OpenGL 3.0 or 3.1 level of support. That's not even good enough for thinking about using it. If somebody commits to adding OpenGL 4.x support into it, maybe then it will have some chance of surviving. If there are volunteers, please discuss it with Dave Airlie. </blockquote><div> </div><div>So the main work would be to add GL specific opcodes/intrinsics to the backend?</div><div>I'd volunteer, but I think lack of time and GL knowledge would prevent me from making any kind of commitment.</div><div> </div><div>Jan</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Marek <div class="HOEnZb"><div class="h5"> On Fri, Jun 5, 2015 at 8:22 PM, Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu">jan.vesely@rutgers.edu</a>> wrote: > > > On Tue, May 26, 2015 at 5:45 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: >> >> On Wed, May 27, 2015 at 12:39 AM, Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu">jan.vesely@rutgers.edu</a>> >> wrote: >> > On Wed, 2015-05-27 at 00:36 +0200, Marek Olšák wrote: >> >> On Tue, May 26, 2015 at 10:19 PM, Emil Velikov >> >> <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: >> >> > On 26/05/15 14:04, Marek Olšák wrote: >> >> >> From: Marek Olšák <<a href="mailto:marek.olsak@amd.com">marek.olsak@amd.com</a>> >> >> >> >> >> >> --- >> >> >> src/gallium/drivers/radeon/radeon_llvm.h | 5 ++--- >> >> >> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 15 >> >> >> +++++++++++---- >> >> >> 2 files changed, 13 insertions(+), 7 deletions(-) >> >> >> >> >> >> diff --git a/src/gallium/drivers/radeon/radeon_llvm.h >> >> >> b/src/gallium/drivers/radeon/radeon_llvm.h >> >> >> index 8612ef8..ec4c343 100644 >> >> >> --- a/src/gallium/drivers/radeon/radeon_llvm.h >> >> >> +++ b/src/gallium/drivers/radeon/radeon_llvm.h >> >> >> @@ -33,7 +33,6 @@ >> >> >> >> >> >> #define RADEON_LLVM_MAX_INPUTS 32 * 4 >> >> >> #define RADEON_LLVM_MAX_OUTPUTS 32 * 4 >> >> >> -#define RADEON_LLVM_MAX_ARRAYS 16 >> >> >> >> >> >> #define RADEON_LLVM_INITIAL_CF_DEPTH 4 >> >> >> >> >> >> @@ -130,8 +129,8 @@ struct radeon_llvm_context { >> >> >> unsigned loop_depth; >> >> >> unsigned loop_depth_max; >> >> >> >> >> >> - struct tgsi_declaration_range arrays[RADEON_LLVM_MAX_ARRAYS]; >> >> >> - unsigned num_arrays; >> >> >> + struct tgsi_declaration_range *arrays; >> >> >> + unsigned max_num_arrays; >> >> >> >> >> >> LLVMValueRef main_fn; >> >> >> >> >> >> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c >> >> >> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c >> >> >> index 8638537..af5eb88 100644 >> >> >> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c >> >> >> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c >> >> >> @@ -85,8 +85,9 @@ get_array_range(struct lp_build_tgsi_context >> >> >> *bld_base, >> >> >> unsigned File, const struct tgsi_ind_register *reg) >> >> >> { >> >> >> struct radeon_llvm_context * ctx = >> >> >> radeon_llvm_context(bld_base); >> >> >> + >> >> >> if (File != TGSI_FILE_TEMPORARY || reg->ArrayID == 0 || >> >> >> - reg->ArrayID > RADEON_LLVM_MAX_ARRAYS) { >> >> >> + reg->ArrayID-1 >= ctx->max_num_arrays) { >> >> >> struct tgsi_declaration_range range; >> >> >> range.First = 0; >> >> >> range.Last = bld_base->info->file_max[File]; >> >> >> @@ -252,8 +253,14 @@ static void emit_declaration( >> >> >> } >> >> >> >> >> >> case TGSI_FILE_TEMPORARY: >> >> >> - if (decl->Declaration.Array && decl->Array.ArrayID <= >> >> >> RADEON_LLVM_MAX_ARRAYS) >> >> >> + if (decl->Declaration.Array) { >> >> >> + if (decl->Array.ArrayID-1 >= >> >> >> ctx->max_num_arrays) { >> >> >> + ctx->max_num_arrays += 32; >> >> >> + ctx->arrays = realloc(ctx->arrays, >> >> > You should use the REALLOC wrapper, considering the FREE below. >> >> > >> >> >> + sizeof(ctx->arrays[0]) >> >> >> * ctx->max_num_arrays); >> >> >> + } >> >> >> ctx->arrays[decl->Array.ArrayID - 1] = >> >> >> decl->Range; >> >> >> + } >> >> >> if (uses_temp_indirect_addressing(bld_base)) { >> >> >> lp_emit_declaration_soa(bld_base, decl); >> >> >> break; >> >> >> @@ -1432,8 +1439,6 @@ void radeon_llvm_context_init(struct >> >> >> radeon_llvm_context * ctx) >> >> >> /* Allocate outputs */ >> >> >> ctx->soa.outputs = ctx->outputs; >> >> >> >> >> >> - ctx->num_arrays = 0; >> >> >> - >> >> >> /* XXX: Is there a better way to initialize all this ? */ >> >> >> >> >> >> lp_set_default_actions(bld_base); >> >> >> @@ -1622,6 +1627,8 @@ void radeon_llvm_dispose(struct >> >> >> radeon_llvm_context * ctx) >> >> >> { >> >> >> LLVMDisposeModule(ctx->soa.bld_base.base.gallivm->module); >> >> >> LLVMContextDispose(ctx->soa.bld_base.base.gallivm->context); >> >> >> + FREE(ctx->arrays); >> >> >> + ctx->arrays = NULL; >> >> > Not particularly familiar with the radeon driver(s) so this might >> >> > come a >> >> > bit silly - shouldn't one zero max_num_arrays at this stage ? >> >> >> >> Yes, I've sent a new patch for that. >> >> > >> >> > Similar counters (temps_count, output_reg_count) seems to be left >> >> > unchanged, while others (branch_depth_max, loop_depth_max) are reset. >> >> >> >> I've sent a patch for temps_count. I'm not touching output_reg_count, >> >> because it's only used by the dying r600g LLVM backend. >> > >> > just out of curiosity, why is it dying? >> >> The OpenGL shader support is dying because the LLVM backend is not >> used by default, it lacks some features, and SB should perform >> equally, if not better. >> >> The LLVM backend is still important for OpenCL though. > > > wouldn't a functioning llvm-r600 backend for OCL, and the fact that SI uses > llvm for graphics mean that GL-llvm-r600 is lower maintenance solution? > I'm not familiar with GL codepaths, is the GL(tgsi)-llvm conversion so > complex (and different from SI) that it's better to use SB? > > jan > >> >> >> Marek > > </div></div></blockquote></div> </div></div>