Git Product home page Git Product logo

shady's Introduction

Shady

shady is a small intermediate shading language and compiler for research purposes. It strives to be a testbed for improved GPU programming models, and also provide support for emulating features either missing from SPIR-V, or suffering from poor support.

Shady is ideal for projects that aim to target SPIR-V, but already make use of features that are not found in vanilla Vulkan compute. See feature support below.

Shady is used as part of the AnyDSL to provide experimental Vulkan accelerator support.

Vcc - the Vulkan Clang Compiler

Shady features a front-end called Vcc that calls into Clang and parses the resulting LLVM IR, giving you effectively a C/C++ to SPIR-V compiler.

This project is called 'Shady' and is the IR/middle-end part of Vcc. Vcc currently does live in this repository, inside src/frontends/llvm and src/driver/vcc.c.

This might change later to keep the IR issues tracked separately. Please check out the Vcc website if you have not already.

Feature support

Not all supported features are listed, these are just the more notable ones that are either already working, or are planned.

  • True function calls (thanks to a CPS transformation)
    • Function pointers/indirect calls
    • Recursion (with a stack)
    • Divergent calls
  • Arbitrary control flow inside functions: goto, including non-uniform is allowed
    • This makes shady easy to target from existing compilers.
    • Reconvergence is explicit and dataflow driven, not reliant on a CFG analysis.
  • Subgroup memory (known as simdgroup in Metal)
  • Physical pointers (cast-able pointers where the layout of objects in memory is observable)
    • For 'private' memory
    • For 'shared' memory
  • 'Wide' subgroup operations (with arbitrary types)
    • Ballot
    • Shuffles
  • Int8, Int16 and Int64 support everywhere
  • FP 64 emulation
  • Generic (tagged) pointers
  • Printf debug support
  • Adapt code generation to the target through a runtime component.

Platform support

  • Compiles on Windows/MacOS/Linux with any C11 compliant toolchain: GCC, Clang and recent versions of MSVC
    • Windows SDKs older than 10.0.20348.0 are missing important C11 features and are unsupported.
    • Will run as far back as Windows XP - using MinGW based toolchains.
    • We ran the compiler on IA32, AMD64, AArch64 and RISCV 64 machines with no issues.
  • The following Vulkan drivers have been tested:
    • radv Open-source mesa driver for AMD GPUs
      • Tested on multiple RDNA2 and GCN devices
    • amdvlk works too
    • anv Open-source mesa driver for Intel GPUs
    • Intel proprietary Windows drivers (UHD 630, A750/A770)
    • NVidia proprietary drivers (requiring a small hack)
    • MoltenVK does not work properly due to issues with SPIRV-Cross
    • Imagination closed-source driver on the VisionFive 2 board: driver crash

Additionally, the compiler supports alternative backends:

  • GLSL (untested - no runtime component yet)
  • ISPC (no runtime component either, but useful for debugging on the host)

Metal shading language and C backends are on the table in the future.

Compiler design

  • Semi-immutable impure IR:
    • Qualified value types (uniform or varying), type system can enforce uniformity for sensitive operations
    • Meta-instructions for conventional structured control flow (if, match, loop), no convergence annotations required
    • Experimental new dynamically structured control flow primitives (paper/writeup coming later)
  • Nodes are either nominal (top-level declarations, variables and basic blocks) or structural (everything else). Structural nodes are immutable and subject to hash-consing and folding ops during construction.
  • Shady is written in standard C11 and requires few dependencies to build: CMake, JSON-C and the SPIRV-Headers.

The grammar is defined in grammar.json, this file is used to define the various nodes in the IR, and generate much of the boilerplate code (node hashing, rewriting, visitors, ...). Some finer concepts are expressed in ir.h or even type.h. There is also a number of x-macros used as "rich" enums.

Language syntax

The textual syntax of the language is C-like in that return types come first. Variance annotations are supported. Overall the language is structurally close to SPIR-V and LLVM, very much on purpose. There is a 'front-end' (slim) variant of the IR that allows for mutable variables and using instructions as values.

// line comments are supported
fn identity varying i32(varying i32 i) {
    return (i);
};

fn f i32(varying i32 i) {
    val j = call(identity, i);
    val k = add(j, 1);
    return (k);
};

const i32 answer = 42;

The textual syntax allows nesting basic blocks inside functions. The syntax is superficially similar to C labels, but with an added parameters list. Note that this is mostly for making handwritten examples look nicer, the actual nesting of functions/continuations is determined by the CFG analysis after name binding.

fn f i32(varying bool b) {
    jump bb1(7);

    cont bb1(varying i32 n) {
        branch (b, bb2(), bb3(n));
    }

    cont bb2() {
        return (0);
    }

    cont bb3(varying i32 n) {
        return (n);
    }
};

shady's People

Contributors

hugobros3 avatar michael-kenzel avatar m-kurtenacker avatar martty avatar stlemme avatar madmann91 avatar sparkypotato avatar

Stargazers

 avatar Chris avatar Nick Clark avatar  avatar Jacob Goodale avatar Larry King avatar Julius Ikkala avatar Max Klyga avatar Zhicheng Wang avatar Sean Isom avatar  avatar  avatar Mutsuha Asada avatar  avatar pudi avatar  avatar Uneven Prankster  avatar sunguangdong avatar Cesar Miquel avatar  avatar SkillerRaptor avatar  avatar harun seng avatar Brad Svercl avatar  avatar HK-SHAO avatar Alec Miller avatar  avatar  avatar Rafael Ristovski avatar  avatar Nikolai Sivertsen avatar Crush avatar Fernando Giardini avatar Felix Maier avatar Lucas avatar Gumelar Purnama Nugraha avatar Adnan Ahmed avatar Yiwei Yang avatar SeungheonOh avatar Denys Mentiei avatar Conscat avatar Nicolas P. Rougier avatar Isaac David avatar  avatar  avatar  avatar  avatar Weiliang Wang avatar fxzjshm avatar  avatar  avatar Balázs Kovács avatar  avatar Brynjard Øvergård avatar  avatar Stefan Asandei avatar Sascha Willems avatar  avatar Linsy avatar Allen Guo avatar  avatar Suraj avatar Noah Cabral avatar  avatar Lodinu Kalugalage avatar Dale Weiler avatar Henrique Ariel Cabral de Almeida avatar Kayla Firestack avatar  avatar Aven avatar Christopher Blanchard avatar  avatar Stanisław Zagórowski avatar tomat avatar  avatar Krzysztof Szenk avatar Filip Miletic avatar  avatar Juan S. Marquerie avatar  avatar Ödön Kalamár avatar Jake Ryan avatar Lou avatar Peter Goodman avatar Davis Morley avatar niansa/tuxifan avatar  avatar  avatar  avatar InspectorGameBoy avatar Rodrigo Oliveira avatar  avatar Ermine avatar Fahri Ali Rahman avatar Shader Coder avatar Riya Bisht  avatar Simone avatar  avatar jadon avatar

Watchers

Allan MacKinnon avatar  avatar Jevin Sweval avatar  avatar James Cloos avatar Richard Membarth avatar Daniel Mazurkiewicz avatar  avatar Arie Leo avatar Julien Barnoin avatar  avatar  avatar  avatar niansa/tuxifan avatar Fernando Giardini avatar  avatar 徐同学 avatar

shady's Issues

lowest vulkan-level / underlying hardware feature required

I understood that shady/vcc targets spir-V , but is an alternative to vulkan/opencl.

Q1a) So what are the GPU hardware minimums (architectural feature requirements)
Q1b) software/backend-driver minimums (versions/level) ?
Q1c) Host-machine+GPU architecture requirements (virtual shared memory, unified shared memory, etc)?

For instance, Consider the recent mesa-nvk driver and rusticl being developed.
Mesa-nvk provides the vulkan support, and rusticl may eventually compile opencl spirv to it.
With vulkan 1.0 there is a chance it can go as far back as Kepler Nvidia cards, and rusticl may have a chance to be able to deliver opencl-1.2 on it.

When vulkan drivers are written, they are tested against the vulkan-CTS, so as to be able to declare that it works upto various vulkan-levels . likewize openCL-CTS.
Q2a) If spirV IR is a superset of, and has more expressive power to specify code than vulkan or openCL, what if a driver implementation has over optimized and hence limited its spir-v compiler implemenation to that subset used by vulkan and opencl. Which component is responsible for/What ensures that all of spir-V is compilable on any given graphics hardware?
Q2b) What should be tested for, in order to know that shady/vcc will work properly, on any given graphics hardware? is there a vcc-CTS?

Evaluate using Profile-Guided Optimization (PGO) and Post-Link Optimization (PLO)

Hi!

Recently I checked Profile-Guided Optimization (PGO) improvements on multiple projects. The results are available here. According to the tests, PGO can help to achieve better performance in many cases for many applications including compilers like Clang, GCC, Rustc, LDC, Go, etc. I think trying to optimize Shady/VCC with PGO can be a good idea.

I can suggest the following action points:

  • Perform PGO benchmarks on Shady. If it shows improvements - add a note to the documentation about possible improvements in Shady's performance with PGO.
  • Providing an easier way (e.g. a build option) to build scripts with PGO can be helpful for the end-users and maintainers since they will be able to optimize Shady according to their workloads.
  • Optimize pre-built Shady binaries (if any).

Testing Post-Link Optimization (PLO) techniques (like LLVM BOLT) would be interesting (Clang and Rustc already use BOLT as an addition to PGO) but I recommend starting from the usual PGO.

Here are some examples of how PGO optimization is integrated into other projects:

Here are some examples of how PGO-related documentation could look in the project:

Below are listed some LLVM BOLT results:

I would be happy to answer your questions about PGO and PLO.

I understand that the project is in the early development stages so features could have a bigger priority than performance. Anyway, in this case, you can treat the issue just like an idea for future improvements.

vcc command fails to compile the example

I try to get vcc working, bu I can't. I'm trying to compile the example from https://shady-gang.github.io/vcc/, but I can't.

$ vcc t.cpp -o e.spv --verbose
clang version 17.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
built command: clang -c -emit-llvm -S -g -O0 -ffreestanding -Wno-main-return-type -Xclang -fpreserve-vec3-type --target=spir64-unknown-unknown -isystem"/usr/local/bin/../share/vcc/include/" -D__SHADY__=1 -o 2H6KmBNdl7kH7NOPtuiZgAMREimob8fd "t.cpp" "--verbose"
clang version 17.0.6
Target: spir64-unknown-unknown
Thread model: posix
InstalledDir: /usr/bin
 (in-process)
 "/usr/bin/clang-17" -cc1 -triple spir64-unknown-unknown -Wspir-compat -emit-llvm -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name t.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -ffreestanding -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/*** -resource-dir /usr/lib/clang/17 -isystem /usr/local/bin/../share/vcc/include/ -D __SHADY__=1 -O0 -Wno-main-return-type -fdeprecated-macro -fdebug-compilation-dir=/home/*** -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -fpreserve-vec3-type -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o 2H6KmBNdl7kH7NOPtuiZgAMREimob8fd -x c++ t.cpp
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target x86_64-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/bin/../share/vcc/include
 /usr/local/include
 /usr/lib/clang/17/include
 /usr/include
End of search list.
t.cpp:5:41: error: unknown type name 'uniform'
    5 | descriptor_set(0) descriptor_binding(1) uniform sampler2D texSampler;
      |                                         ^
t.cpp:5:58: error: expected ';' after top level declarator
    5 | descriptor_set(0) descriptor_binding(1) uniform sampler2D texSampler;
      |                                                          ^
      |                                                          ;
t.cpp:7:24: error: no matching constructor for initialization of 'input vec3' (aka '__attribute__((address_space(389))) vec3_impl<native_vec3, float>')
    7 | location(0) input vec3 fragColor;
      |                        ^
/usr/local/bin/../share/vcc/include/shady_vec.h:57:5: note: candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(389)))'
   57 |     vec3_impl() {}
      |     ^
/usr/local/bin/../share/vcc/include/shady_vec.h:58:5: note: candidate constructor not viable: requires single argument 'scalar', but no arguments were provided
   58 |     vec3_impl(T scalar) : x(scalar), y(scalar), z(scalar) {}
      |     ^         ~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:60:5: note: candidate constructor not viable: requires single argument 'n', but no arguments were provided
   60 |     vec3_impl(Native n) : x(n.x), y(n.y), z(n.z) {}
      |     ^         ~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:53:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
   53 | struct vec3_impl {
      |        ^~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:53:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided
   53 | struct vec3_impl {
      |        ^~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:59:5: note: candidate constructor not viable: requires 3 arguments, but 0 were provided
   59 |     vec3_impl(T x, T y, T z) : x(x), y(y), z(z) {}
      |     ^         ~~~~~~~~~~~~~
t.cpp:8:24: error: no matching constructor for initialization of 'input vec2' (aka '__attribute__((address_space(389))) vec2_impl<native_vec2, float>')
    8 | location(1) input vec2 fragTexCoord;
      |                        ^
/usr/local/bin/../share/vcc/include/shady_vec.h:91:5: note: candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(389)))'
   91 |     vec2_impl() {}
      |     ^
/usr/local/bin/../share/vcc/include/shady_vec.h:92:5: note: candidate constructor not viable: requires single argument 'scalar', but no arguments were provided
   92 |     vec2_impl(T scalar) : x(scalar), y(scalar) {}
      |     ^         ~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:94:5: note: candidate constructor not viable: requires single argument 'n', but no arguments were provided
   94 |     vec2_impl(Native n) : x(n.x), y(n.y) {}
      |     ^         ~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:87:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
   87 | struct vec2_impl {
      |        ^~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:87:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided
   87 | struct vec2_impl {
      |        ^~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:93:5: note: candidate constructor not viable: requires 2 arguments, but 0 were provided
   93 |     vec2_impl(T x, T y) : x(x), y(y) {}
      |     ^         ~~~~~~~~
t.cpp:10:25: error: no matching constructor for initialization of 'output vec4' (aka '__attribute__((address_space(390))) vec4_impl<native_vec4, float>')
   10 | location(0) output vec4 outColor;
      |                         ^
/usr/local/bin/../share/vcc/include/shady_vec.h:23:5: note: candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(390)))'
   23 |     vec4_impl() {}
      |     ^
/usr/local/bin/../share/vcc/include/shady_vec.h:24:5: note: candidate constructor not viable: requires single argument 'scalar', but no arguments were provided
   24 |     vec4_impl(T scalar) : x(scalar), y(scalar), z(scalar), w(scalar) {}
      |     ^         ~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:26:5: note: candidate constructor not viable: requires single argument 'n', but no arguments were provided
   26 |     vec4_impl(Native n) : x(n.x), y(n.y), z(n.z), w(n.w) {}
      |     ^         ~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:19:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
   19 | struct vec4_impl {
      |        ^~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:19:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided
   19 | struct vec4_impl {
      |        ^~~~~~~~~
/usr/local/bin/../share/vcc/include/shady_vec.h:25:5: note: candidate constructor not viable: requires 4 arguments, but 0 were provided
   25 |     vec4_impl(T x, T y, T z, T w) : x(x), y(y), z(z), w(w) {}
      |     ^         ~~~~~~~~~~~~~~~~~~
t.cpp:13:26: error: use of undeclared identifier 'texSampler'
   13 |     outColor = texture2D(texSampler, fragTexCoord) * (vec4) { fragColor.x * 2.5f, fragColor.y * 2.5f, fragColor.z * 2.5f, 1.0f };
      |                          ^
6 errors generated.
Clang returned 256 and replied:

Honestly, I'm not surprised by the first message since "uniform" is nowhere to be found in the header.

VCC not compiling for graphics pipelines

btw it's probably not me having corrupted anything with a git clone or anything, I cloned it with the recursive flag and I tried it again after pulling just to be sure! This is the errors I got in my Vulkan code, keep in mind that when I wrote it in GLSL it worked just fine.
Most notible is the part mentioning Operand 3 requiring Kernel and GroupNonUniform capabilities which are generally known for not being available in Graphics Pipelines (afaik)

Validation layer: Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08737 ] | MessageID = 0xa5625282 | vkCreateShaderModule(): pCreateInfo->pCode (spirv-val produced an error):
Operand 3 of Decorate requires one of these capabilities: Kernel GroupNonUniform
OpDecorate %subgroup_id BuiltIn SubgroupId
. The Vulkan spec states: If pCode is a pointer to SPIR-V code, pCode must adhere to the validation rules described by the Validation Rules within a Module section of the SPIR-V Environment appendix (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08737)
Validation layer: Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08737 ] | MessageID = 0xa5625282 | vkCreateShaderModule(): pCreateInfo->pCode (spirv-val produced an error):
Operand 3 of Decorate requires one of these capabilities: Kernel GroupNonUniform
OpDecorate %subgroup_id BuiltIn SubgroupId
. The Vulkan spec states: If pCode is a pointer to SPIR-V code, pCode must adhere to the validation rules described by the Validation Rules within a Module section of the SPIR-V Environment appendix (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08737)
Validation layer: Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-layout-07988 ] Object 0: handle = 0xee647e0000000009, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0xec4bec000000000b, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; | MessageID = 0x215f02cd | vkCreateGraphicsPipelines(): pCreateInfos[0].pStages[0] SPIR-V (VK_SHADER_STAGE_VERTEX_BIT) uses descriptor slot [Set 0 Binding 0] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) but was not declared in the pipeline layout. The Vulkan spec states: If a resource variables is declared in a shader, a descriptor slot in layout must match the shader stage (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkGraphicsPipelineCreateInfo-layout-07988)

Here is the Vertex Shader (shader.vert.c):

#include <shady.h>

location(0) output vec3 fragColor;

vec2 positions[3] =
{
    (vec2){0.0f, -0.5f},
    (vec2){0.5f, 0.5f},
    (vec2){-0.5f, 0.5f}
};

vec3 colors[3] =
{
    (vec3){1.0f, 0.0f, 0.0f},
    (vec3){0.0f, 1.0f, 0.0f},
    (vec3){0.0f, 0.0f, 1.0f}
};

vertex_shader void main()
{
    gl_Position = (vec4){positions[gl_VertexIndex].x, positions[gl_VertexIndex].y, 0.0f, 1.0f};
    fragColor = colors[gl_VertexIndex];
}

Here is the Fragment Shader (shader.frag.c):

#include <shady.h>

location(0) input vec3 fragColor;

location(0) output vec4 outColor;

fragment_shader void main()
{
    outColor = (vec4){fragColor.x, fragColor.y, fragColor.z, 1.0f};
}

probably the most relevent section in the C++ part where I just get every feature from every version of the api (fyi my hardware is not the problem or atleast I don't think it is, also most of it is not my code so don't judge me I'm an idiot):

void createLogicalDevice()
{
	QueueFamilyIndices indices = findQueueFamilies(m_PhysicalDevice, m_Surface);

	std::vector<VkDeviceQueueCreateInfo> queueCreateInfos;
	std::set<uint32_t> uniqueQueueFamilies =
	{
		indices.graphicsFamily.value(),
		indices.presentFamily.value()
	};

	float queuePriority = 1.0f;
	for (uint32_t queueFamily : uniqueQueueFamilies)
	{
		VkDeviceQueueCreateInfo queueCreateInfo{};
		queueCreateInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
		queueCreateInfo.queueFamilyIndex = queueFamily;
		queueCreateInfo.queueCount = 1;
		queueCreateInfo.pQueuePriorities = &queuePriority;
		queueCreateInfos.push_back(queueCreateInfo);
	}

	VkPhysicalDeviceFeatures deviceFeatures{};
	vkGetPhysicalDeviceFeatures(m_PhysicalDevice, &deviceFeatures);

	if (deviceFeatures.shaderInt16 == VK_FALSE || deviceFeatures.shaderInt64 == VK_FALSE)
		throw std::runtime_error("Your device doesn't support the required features");

	VkPhysicalDeviceVulkan11Features vk11Features{};
	vk11Features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_1_FEATURES;

	VkPhysicalDeviceVulkan12Features vk12Features{};
	vk12Features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_2_FEATURES;
	vk12Features.pNext = &vk11Features;

	VkPhysicalDeviceVulkan13Features vk13Features{};
	vk13Features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_3_FEATURES;
	vk13Features.pNext = &vk12Features;

	VkPhysicalDeviceFeatures2 deviceFeatures2{};
	deviceFeatures2.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2;
	deviceFeatures2.pNext = &vk13Features;
	deviceFeatures2.features = deviceFeatures;

	vkGetPhysicalDeviceFeatures2(m_PhysicalDevice, &deviceFeatures2);

	VkDeviceCreateInfo createInfo{};
	createInfo.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO; 
	createInfo.pNext = &deviceFeatures2;

	createInfo.queueCreateInfoCount = static_cast<uint32_t>(queueCreateInfos.size());
	createInfo.pQueueCreateInfos = queueCreateInfos.data();

	createInfo.enabledExtensionCount = static_cast<uint32_t>(m_DeviceExtensions.size());
	createInfo.ppEnabledExtensionNames = m_DeviceExtensions.data();

	if (enableValidationLayers)
	{
		createInfo.enabledLayerCount = static_cast<uint32_t>(m_ValidationLayers.size());
		createInfo.ppEnabledLayerNames = m_ValidationLayers.data();
	}
	else
		createInfo.enabledLayerCount = 0;

	if (vkCreateDevice(m_PhysicalDevice, &createInfo, nullptr, &m_Device) != VK_SUCCESS)
		throw std::runtime_error("Failed to create logical device!");

	vkGetDeviceQueue(m_Device, indices.graphicsFamily.value(), 0, &m_GraphicsQueue);
	vkGetDeviceQueue(m_Device, indices.presentFamily.value(), 0, &m_PresentQueue);
}

Sorry if I'm making your life harder through bad bug reports or just horrible code.

Resource binding roadmap?

The example language is using GLSL/HLSL-like resource binding.

I find this resource binding horrible and complex. On the other hand, Metal 3.0 resource binding
API is the simplest and most powerful at the same time. You don't need the complexity of DX12 and Vulkan.

Are there any plans for moving to essentially what CUDA/OpenCL/Metal do?

You simply declare a standard C/C++ struct with data, GPU pointers and sampler/texture handles
and pass them as a regular function parameters.

ispc broken?

ispc code generator seems to be broken for a while now.

It looks like the code emission produces many errors like in a aobench sample:

/tmp/shady/build/samples/aobench/aobench.ispc:25:43: Error:
"uniform" qualifier is illegal with "void" type.
export void (aobench_kernel)(uniform void * uniform _30);
^^^^^^^^^

aobench crash

Cool project!

I am trying to run aobench sample and I get a segmentation fault on linux.
(two Vulkan devices: AMD Radeon Graphics (RADV RENOIR), and NVIDIA GeForce RTX 3050 Laptop GPU)

There are several messages before the crash:
'LEA used on a pointer to a non-array type!'

Namespaced attributes

I'd put things like descriptor_set or descriptor_binding in a vcc or shady namespace.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.