heroseh / hcc Goto Github PK

I currently have a issue in the renderdoc github issue tracker. The renderdoc developer has kindly fix one of the issues very fast but more have cropped up and hopefully will be fixed very soon. baldurk/renderdoc#2911

I'll post updates here, when i know more

The SPIR-V files that HCC produces currently crash the AMD driver on Windows only in VkCreateShaderModule, AMD are kindly working on a fix! https://community.amd.com/t5/opengl-vulkan/vkcreateshadermodule-crashes-in-amdvlk64-dll/td-p/595903

I'll update this issue when i know more

I have a function (in GLSL) :

bool solve_cubic(out vec3 out_roots, vec4 coeffs)
{
....
}

where I am returning multiple values as out parameter.

In the second example I want to apply a function to some data:

void some_function(float* data, int size) {

}

My understanding is that pointers are not supported in hcc. What is the recommended
way of doing this in hcc?

Thanks.

Hey, I'm also working on a C to Vulkan SPIR-V compiler which can be found at https://gitlab.com/nanokatze/cg2c/. Here are a bunch of example shaders:
https://gitlab.com/nanokatze/cg2c/-/blob/master/test/hello/fft_shader.c
https://gitlab.com/nanokatze/cg2c/-/blob/master/test/hello/llama_shader.c
https://gitlab.com/nanokatze/cg2c/-/blob/master/test/hello/llama2_shader.c

Yes, it does actually work.

Perhaps you will find it useful as a reference.

My compiler seems to build on stricter assumptions from those yours is built upon. For example, we don't do logical pointers here. Generic addressing 4 life! It outright requires certain features like bufferDeviceAddress and shaderInt8. This would preclude it from being translatable to current HLSL/DXIL as there's no equivalents to these features. Opaque types like images are eschewed as well, instead hidden behind some ordinary data (integer handles), which makes bindless images a prerequisite.

Anyway, to address entries from your TODO list:

goto statement

As you should've already noticed, SPIR-V doesn't allow you to branch to any random block, requiring you to explicitly say loops and ifs. One reason to do this is to maintain convergence information, i.e. so that subgroup ops or "wave intrinsics" if you prefer have sensible behavior in certain constructs. E.g. consider the following GLSL snippet

int invocationsWithSameValue(int x) {
 int y;
 for (;;) {
  if (x == subgroupBroadcastFirst(x)) {
   y = subgroupAdd(1);
   break;
  }
 }
 return y;
}

if you only have control flow graph alone, without explicit merge points like SPIR-V, this isn't distinguishable from

int invocationsWithSameValue(int x) {
 int y;
 for (;;) {
  if (x == subgroupBroadcastFirst(x)) {
   break;
  }
 }
 y = subgroupAdd(1);
 return y;
}

(please draw the CFGs by yourself)

This is to say, goto is possibly implementable with some effort. Loops formed with goto will be varying degrees of bad: unspecified tangles (sets of invocations) for subgroup ops/wave intrinsics, etc. Forward goto (i.e. equivalent of multibreak) would be perfectly fine though.

thin gpu emulator

Use lavapipe

vectors and matrix extensions

These are only important as syntactic conveniences. Don't worry about not making use of OpTypeVector or especially OpTypeMatrix. All drivers in Mesa for example share the compiler which destructs matrix types and ops into corresponding vector ops as SPIR-V is being ingested, and then vector ops are exploded into scalar ops, because working with vectors is kinda bad.

For load/stores in particular, vector types can help but you could also likely achieve an equivalent effect by specifying stricter alignment for your loads and stores, and loading and storing the compound types at once.

Cool project.

Is there a tentative roadmap for this project in terms of new features?