chaoticbob / tinyrenderers Goto Github PK

View Code? Open in Web Editor NEW

463.0 25.0 27.0 9.08 MB

C++ 99.54% C 0.01% CMake 0.45%

tinyrenderers's Introduction

tinyrenderers

Single header implemenations of Vulkan and D3D12 renderers

Features

Single header for Vulkan renderer
Single header for D3D12 renderer
Texture upload + mipmap generation (better quality resizer coming soon)
Simplified API shared between both renderers
C style structs
Support for Vulkan layers
Configurable swapchain multi-sample
Configurable swapchain imagecount
Configurable swapchain depth/stencil attachment
Samples use GLFW
- GLFW
  - Works for both Vulkan and D3D12 - renderer takes over after window handle is obtained
  - Image loading done via stb_image
Includes basic compute samples
Uses CMake
...more to come soon

Notes

Linux and Windows only for the moment
- Tested on open source intel driver on Linux
- Tested on AMD and NVIDIA drivers on Windows
- For best results, use latest drivers
Vulkan renderer will work with C/C++
- For best results, use latest version of Vulkan SDK
D3D12 render requires C++
Microsoft's C compiler doesn't support certain C11/C99 features, such as VLAs (so alot of awkward array handling)
tinyvk/tinydx is written for experimentation and fun-having - not performance
For simplicity, only one descriptor set can be bound at once
- In D3D12, this means two descriptor heaps (CBVSRVUAVs and samplers)
- For Vulkan shaders the 'set' parameter for 'layout' should always be 0
- For D3D12 shaders the 'space' parameter for resource bindings should always be 0
Vulkan like idioms are used primarily with some D3D12 wherever it makes sense
For Vulkan, host visible means both HOST VISIBLE and HOST COHERENT
Bring your own math libraary
Development was done on Cinder but renderers are not limited to it

Compiling and Linking

In one C/C++ file that #includes the renderer's header file, do this:

#define TINY_RENDERER_IMPLEMENTATION
#include "tinyvk.h"

#define TINY_RENDERER_IMPLEMENTATION
#include "tinydx.h"

Building on Linux

git clone --recursive [email protected]:chaoticbob/tinyrenderers.git
cd tinyrenderers
mkdir build
cd build
cmake ..
make

Ubuntu and variants will require the follow packages

libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev

Building on Windows

git clone --recursive [email protected]:chaoticbob/tinyrenderers.git
cd tinyrenderers
mkdir build
cd build
cmake -G "Visual Studio 14 2015 Win64" ..

Open tinyrenderers.sln and go

Screenshots

Change Log

[2017/11/12] - Added simple tessellation shader sample. Fixed misc issues with pipeline setup for tessellation. [2017/11/10] - Added ChessSet demo. Added geometry shader sample. Fixes to depth stencil handling. [2017/11/10] - Added TexturedCube sample. Updated depth attachment handling on swapchain render pass. Switched out lc_image for stb_image. Added DXC shader build script. [2017/05/27] - Fixed some annoying buffer state transitions. Added build script for shaders. Updated shader naming convention to be more exact. Added OpaqueArgs and PassingArrays for investigation.
[2017/05/20] - Updated Append/Consume sample for Vulkan. Requires latest glslang. ConstantBuffer also works for both platforms.
[2017/05/13] - Added Linux support. Moved to project files to cmake. Moved glsl shaders to glsl sub directory - forcing HLSL for now.
[2017/04/30] - Clarified shader usage in some sample programs to point out which source they're coming from.
[2017/04/27] - Added ConstantBuffer sample (D3D12 only for now). Updated Vulkan samples to use negative viewport height.
[2017/04/25] - Updated SimpleCompute and StructuredBuffer to work on Vulkan.
[2017/04/24] - Added compute samples (D3D12 only for now). One for simple compute and another for structured buffers.

tinyrenderers's People

Contributors

Stargazers

Watchers

tinyrenderers's Issues

tinyvk resize problem

window crashed on resize or minimize, is there anything i can do to prevent that?

vk header transitions swapchain images without first acquiring them

This isn't allowed every swapchain image must be acquired before you can do any access with it.

Instead you can set the initial layout to undefined instead of present after acquiring them in the render loop. It is always valid to put undefined as the initial layout in a transition if you don't care about preserving the data.

Vulkan memory allocator (VMA) support?

I submit our request...

Plan to share common code between two renderers?

That would make maintenance easier in long term.

Why do the samples use 3 swap chain buffers?

I see in the samples code, three command lists are created, three buffers are created but only one is used because s_frame_count always stays 0. I thought the whole point of having three buffers was to be able to submit 2 but the samples always wait after presenting.
So whats the point of creating three swapchain buffers or command lists?

Support planned for DirectX raytracing?

Multiple attachment and multisample textures is broken and lacks robustness

Issue stemming from #18

I looked at this a bit more and it seems like the move here maybe to better align TR's API with how DX works with multiple sample images. I played around with some changes which I'll put up on a branch later today.

High level list of changes:

Added attachment parameter to tr_cmd_render_target_transition
Added tr_cmd_resolve_image to resolve a single texture uses the format from single sample texture (not sure if this is the best thing)
Added tr_cmd_resolve_render_target to resolve all attachments assuming their states are the same
Removed the automatic resolve in tr_internal_dx_cmd_end_render

Here's what the function signatures look like:

tr_api_export void tr_cmd_render_target_transition(tr_cmd* p_cmd, tr_render_target* p_render_target, uint32_t attachment_index, tr_texture_usage old_usage, tr_texture_usage new_usage);

tr_api_export void tr_cmd_resolve_image(tr_cmd* p_cmd, tr_texture* p_src_texture, tr_texture_usage src_current_usage, tr_texture_usage src_final_usage, tr_texture* p_dst_texture, tr_texture_usage dst_current_usage, tr_texture_usage dst_final_usage);

tr_api_export void tr_cmd_resolve_render_target(tr_cmd* p_cmd, tr_render_target* p_render_target, tr_texture_usage ms_current_usage, tr_texture_usage ms_final_usage, tr_texture_usage ss_current_usage, tr_texture_usage ss_final_usage);

Let me know what you think.

Unnecessary Calculations Performed in draw_frame

The code in ChessSet.cpp below can be safely moved into the init function, and doesn't need to be calculated every frame

        g_chess_board_1_solid.SetColor(float3(0.23f));
	g_chess_board_2_solid.SetColor(float3(0.88f));
	g_chess_pieces_1_solid.SetColor(float3(0.85f, 0.3f, 0.3f));
	g_chess_pieces_2_solid.SetColor(float3(0.4f, 0.4f, 0.8f));

	float3 eye = float3(0, 7, 12);
	float3 look_at = float3(0, 0, 0);
	g_camera.LookAt(eye, look_at);
	g_camera.Perspective(65.0f, (float)g_window_width / (float)g_window_height);

	g_chess_board_1_solid.SetView(g_camera);
	g_chess_board_2_solid.SetView(g_camera);
	g_chess_pieces_1_solid.SetView(g_camera);
	g_chess_pieces_2_solid.SetView(g_camera);

	g_chess_pieces_1_wireframe.SetView(g_camera);
	g_chess_pieces_2_wireframe.SetView(g_camera);

Vulkan barrier stages are wrong

BOTTOM_OF_PIPE/TOP_OF_PIPE are used with srcAccessMask/dstAccessMask != 0. These stages do not access memory, so any memory barrier on these stages is wrong. ALL_COMMANDS_BIT -> ALL_COMMANDS_BIT would accomplish the same thing.

Crash when resizing window

When running on Ubuntu 17.10, Radeon R9 Nano with the latest drivers (oibaf PPA), samples crash when resizing the window (eg. 03_UniformBuffer_VK):

#3  0x00007ffff5d64fc2 in __GI___assert_fail (assertion=0x5555555ad780 "VK_SUCCESS == vk_res", file=0x5555555acbe8 "/home/glaze/Downloads/tinyrenderers/tinyvk.h", line=5459, 
    function=0x5555555b1d20 <tr_internal_vk_acquire_next_image(tr_renderer*, tr_semaphore*, tr_fence*)::__PRETTY_FUNCTION__> "void tr_internal_vk_acquire_next_image(tr_renderer*, tr_semaphore*, tr_fence*)") at assert.c:101
#4  0x0000555555576d05 in tr_internal_vk_acquire_next_image(tr_renderer*, tr_semaphore*, tr_fence*) ()
#5  0x000055555556b10d in tr_acquire_next_image ()
#6  0x000055555559251f in draw_frame() ()
#7  0x0000555555592a46 in main ()

Can add support for Metal?

Hi,
your project is very nice but of next gen APIs is lacking Metal support.. with that could be a perfect playground for testing all APIs.. Altough we could test using MoltenVK (vulkan to metal wrapper) now that it even provides compute shader support, better could be native Metal support.. note also spirv-cross has gained compute also recently..
Are you interested on implementing support for it?

How did you translate hlsl to spirv

How did you translate hlsl to spirv, is there any tools?