johnfea
johnfea
No, I was just trying to fix CLA check failing.
> @johnfea Reviving this, sorry for the delay, it's been a busy last several weeks. Would you mind doing a rebase on top of the current main so we get...
I mean what I discussed [above](https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/1825#issuecomment-2188580273). Here's the code structure: ``` if (m_supports_avx512f) { switch (m_vector_width) { case 16: break; case 8; // Removing this old case doesn't change test...
This one needs to be accepted before I can work on the others. Due to changes there's again trivial merge conflict in ci.yml.
I also tried to debug a bit why "closure-string" test fails with batched avx2. oslexec/wide/wide_opclosure.cpp: in void init_closure_component() casting ClosureComponent* there into MicrofacetParams* printed the same wrong hash for ustringhash...
The problem was indeed in llvm_gen_closure function: src/oslexec/batched_llvm_gen.cpp: ``` "llvm::Value* loaded = rop.llvm_load_value(sym.." ``` src/liboslexec/batched_backendllvm.cpp: ``` "llvm::Value*BatchedBackendLLVM::llvm_load_value(const Symbol& sym.." "ll.constant(string_val);" ``` src/liboslexec/llvm_util.cpp: ``` "llvm::Value* LLVM_Util::constant(ustring s)" ``` This function already...
I enabled ustringhash_pod for all files in liboslexec/wide/. However, there's issues with the patch. All string parameters there are now ustringhash_pod and according to this error i64 is being inputted...
There's now more code to support ustringhash_pod for batched. Some string variables from .osl files get passed as ustrings into liboslexec/wide functions while ustringhash is expected, I didn't find where...
> Was this only to try and fix bugs you were seeing with hash values being passed in, or were there other reasons you had? My first reason was performance....
> > Some string variables from .osl files get passed as ustrings into liboslexec/wide functions while ustringhash is expected, I didn't find where that is set. > > You might...