all8up / cpf Goto Github PK

Create a utility library which encapsulates common bits of needed graphics utilities. The general contents will wrap up index/vertex buffer creation and texture creation/load as synchronous helpers.

Current image views are created in different manners. There is embedded code to create standard image views versus depth image views, this should all be in the image view initializer itself.

The current register solution is not particularly good. The registers are shared by all clients of the scheduler and that makes it easy to goof things up. Instead, allow the clients to register the items they want in a style similar to thread locals done by the Os (not the compiler version), so GetTLS/SetTLS style.

After breaking out the debug ui, the remaining graphics adapter library should be relatively easy to make header only.

Various buffer types need separated views instead of the current merged version. The higher level rendering systems can wrap that up later.

The current solution to upload buffers and images should be removed and application controlled staging should be performed. The staging will eventually be wrapped up in a higher level render driver.

Should it remain a static library, a header only etc? I tend to lean towards maintaining it as a static link library.

Given the usage patterns, iBuffer as a base to everything would probably make more sense across the backend API's. Even with D3D12 you still discuss it as upload/readback 'buffers' though they are called resources by the API.

Currently there are clear values in both the images when setup and in the render passes, decide on one or the other and figure out how to support it.

Something during the transition seems to have broken the timing systems.

The resource system should be moved out to become a plugin.

Currently the adapter uses a dll version of SDL2. When converted to the static build linking issues occur which make limited sense.

iResourceBinding
iShader
iPipeline

Should have hash functions for compilation, materials and other items.

This should likely be done along with and extension to the IDL which attaches meta data to interfaces. I.e. in the IDL hashing would be added as:
[hash]
interface thing {...}

It is possible to change the application to a plugin, should it be?

Plugins go through different setup paths if they are directly linked versus dynamically loaded. The system needs a unifying wrapper such that the end consumer of the plugin does not need to know the difference.

A common need for most of the systems is a pool allocator.

Currently there are some outlines of possible directions to take in describing the multicore stages in the experimental d3d12 application. Decide on the best solution and implement it.

Vulkan has no concept of a count on fences and this is a D3D12 only thing. Downside of this is needing multiple fences to go with various buffers but it really is not a horrible issue.

https://github.com/vivkin/gason

Occasionally builds will fail due to plugin copies which happen before or during build of the plugin. Need a solution to get the dependencies resolved prior to the copy.

The iPlugin.dll for C# needs to exist as a standard dll. I would contain only the type information for the iPlugin type such that both the binding dll and multiple plugins share the same definition. Since the binding will load on application initialization and immediately use the iPlugin interface, plugins will share the correct type and things should work as intended.

In Vulkan certain bits of the pipeline are inherited from the renderpass in the primary command buffer to the secondary buffers. For instance, the render targets set in the renderpass are set in all of the secondary buffers. This is not happening in the d3d12 simulation of primary/secondary buffers. Oops...

The potential solution is to overload the begin function such that the secondary buffers can grab the render target settings from the pass setup. This would be ignored by the Vulkan driver.

The applications have been through serious iterations and need a clean up pass.

Until the rendering drivers are further along, should probably remove all the extraneous fluff and focus on a single testbed.

The list of swizzles is rather insane.

Need to add support for events. The support should be able to describe dispatch type (immediate or queued) threading expectations (runs on main thread or free threaded) and binding type (single handler or multiple).

Should probably support a property type so each language can support getter/setters in the best manner.

Currently the ansi c file system adapter is a static library, move it to a plugin.

Really don't need to be rebuilding the dependencies with the project.

Use a json document to outline the plugins to load.

If the d3d12 driver continues moving forward it should be moved into a plugin so it can be developed at a different rate than the current plan of just using BGFX for the time being.

While BGFX has some nice bits to it, the structure is unfortunately based on old DX11 and lower designs. The purpose of this project is to focus on Metal, Vulkan and D3D12 with heavy multi-threading which means multiple submission queues and fine grained interaction.

Currently the setup for output ends up causing debug/release/etc to be in paths fed to the application during build. This makes packaging difficult and needs to change. Likely the best approach would be to change the binary output directories such that the very first part of the path is the configuration and then the rest is under that.

The threading library is such a light wrapper that it makes sense moving the library to header only.

The binding layer for CSharp needs to be linked to by the application and plugins, so it must be a normal dll and it should be loaded by the application by default, otherwise the possibility of multiple instances exists which breaks things.

The time library should become a header only library. The primary difficulty is the time ratio initialization and static storage of the ratio.

The current handle pool solution is pretty good for some things but has some annoyances, go through it and figure out how to clean up the usage patterns and perhaps a better solution.

Currently the debug ui code is embedded in the graphics adapter, it needs to be broken out. Likely it will move to a plugin.

Should it become a dll only or move to a plugin?