jessydl / paradigm Goto Github PK
View Code? Open in Web Editor NEWC++20 Vulkan and GLes rendering engine
Home Page: https://paradigmengine.dev
C++20 Vulkan and GLes rendering engine
Home Page: https://paradigmengine.dev
To complete #64 first step we should implement a container type that can do most of the functionality staged_sparse_array
can do, with exclusion of dealing with non-trivial types (i.e. types that don't satisfy std::is_trivial
).
Dynamic instance data currently needs to clear the bundle's instance data to write its data in, as a result this leads to static data that is only uploaded once when they get added to also be cleared. Additionally this leads to an issue where if you add 3 static instances, remove the middle one, you end up with a hole.
Currently instance ID's are additionally their direct offsets in memory for the given geometry. These should be abstracted away (possible using the same container type as the sparse arrays are). This would of-course cause a lookup per ID, but this pales in comparison to the cost of transferring the data anyway. Most would be contiguous anyway.
As an advantage this would mean we are much more able to compartmentalize instance data upload, promoting long lived data to more stable regions of memory while dynamic data is in the more volatile region.
It would also be okay to implement an intermediate solution that just keeps static and dynamic data separate, as dynamic data is updated per-frame anyway, though we still run into the problem of dealing with static data when it's removed.
The feature introduced in PR #51 currently lacks an implementation on CLang 14 and earlier. When std::source_location
becomes available, remove the wrapper code, and clean up the printer.
Current codepath for vulkan texture loading doesn't check for supported formats. Resolve this and gracefully handle, or error out.
Add missing CI workflow for Ubuntu GLES combination
Currently the MaterialData
binding's backing storage is "set once, change never". This can work for toy examples but is bad for actual production.
Proposed changes (choose one):
Advantage:
Cons:
Implementing this in bundles has the distinct advantage that materials already store their instance data there
Pros:
Cons:
Implement material data handling in either bundles/material (prefer bundles), defer to a global buffer unless size exceeds N bytes, or global buffer runs out of size. When global buffer runs out of size, either allocate 2nd global buffer or do smaller self managed allocations.
Pros:
Cons:
Currently no method of automated builds for Android exist, resolve this.
What is expected:
The ECS state should be fully de/serializable, this includes all the components, and the to-be-processed state. Potentially we serialize the filters as well, but these are less important as that's internal optimization.
Registered systems are not to be serialized.
Note that support for deserializing into an already modified ECS state is considered an "extra" and not necessary.
Investigate an alternative approach, and then wholesale replace the existing resource loading system.
The alternative will have these constraints and goals:
* immutable authoritive source seems to be impossible without large efforts in architecture as when f.e. a buffer is loaded we obviously need to be able to write to it if it's used for those purposes.
The current approach selects the "last loaded" to be the authoritive source of what is the disk based assets (for the find
method), but allows load to be called N times and get a fresh version as if just loaded from disk
As the system has been implemented using coroutines, you can simply use co_await
in the construct
method and await for you relevant signal to fire, or to switch to other threads.
All resources are always tracked by default. This isn't toggleable for now (this is to satisfy the safe resource destruction requirement). However, you can control when resources get destroyed if it's safe to do so (i.e. the last references are held by the cache, and the caller). The try_destroy
method will verify if it's safe, and will destroy the resource within the given scope.
Alternatively, the unsafe_destroy
will forcibly destroy the resource. This functionality is hidden behind the RESOURCE_ALLOW_UNSAFE
define.
consider renaming construct
to co_construct
/s
psl::serialization
needs some additional work to allow for polymorphic serialization irrespective of the used encoder/decoder.
Currently there is no iwgpu layer implementation for pipelines, or pipeline caching. These are required for the agnostic abstraction layer, and as well for the convenience when targeting just the webgpu backend.
The stringifying of typenames cannot deal with templated types correctly cross platform (issue related to NTTP & defaulted template args). Either we reject NTTPs (would require considerable parsing), and figure out a solution to sidestep defaulted template args (MSVC differs from GCC/CLang), or reject all templated names for the time being.
Documentation should be generated through the CI every PR merge (or every commit to develop
)
Ideally the documentation would be accessible online versioned. This could be achieved by having versioned folders based on tag on gh-pages
branch i.e.:
root
0.1.0/**
0.1.1/**
all_files_current_develop
Currently filters use the component key, and do a lookup just when the filtering operation is done. This could be improved by having the component container be used instead (when available), and fall back to the key behaviour.
Due to the requirements of std::is_trivially_constructible
we cannot have constructors with side effects for serializable types. Add the ability to have a "prototype" function of some sort allowing the user to specify a "good default value" for a new instance.
This works as the only time new objects get created is either from a known position (from the type system's perspective), or from known data (deserialization and internal stack).
PR #78 introduced stage_t
and stage_range_t
, we should use these in all user facing layers in favour of the hard-coded numeric values.
Currently the psl::serialization
system requires a serialization_name
to be present in the serialization supported objects. This currently is a const char[]
where users need to explicitly write the size of the buffer. Modify this so the user either doesn't need it (unlikely), or where the size of this is known automatically.
The way the packs are handled internally in the ecs state results in some copying; as the indirect packs are managing their own memory (the indices only), this results in some overhead for copying. If we make the indirect packs as lightweight as the direct packs (by using the state's internal cache), then we can remove quite a bit from this overhead.
As PR #101, apply this to details::staged_sparse_array.
App currently doesn't recover from going to sleep/background on the Android platform.
goal: app gracefully can go to background for any time, any duration, and either reboots, or continues execution.
Look into tracking bulk erase operations, and compact after the erasions have been completed (lowering the amount of moving memory significantly)
Severity: High (causes non-fatal issue, and recovers next frame)
Issue:
GPU memory can get trashed when realloc happens in a buffer when, in a single frame, range A moves, followed by range B reallocs onto the old range A location. This results in a frame where the affected commands interacting with that region of memory can get incorrect results (f.e. in the case of rendering geometry, usually a "jitter" is observed). This recovers the next frame as the correct offsets are recorded.
Possible resolution:
Implement a mechanism to mark regions of memory as locked
while they are in flight, deferring their dealloc. Let these locks be attached to preferably a user controllable solution, so that we can solve this using fences for this instance, and potentially barriers/others in case of other user defined use cases.
Support basic animated models using skeletal animation keyframes. Dealing with import is left for the assembler
project.
Preferably the implementation is done through compute shaders for the transformations, but is not a requirement. If not implemented through compute, it is considered a defect that has to be resolved before 1.0.0
Compute shaders can already be loaded, but have some edge cases in resource handling and dependency tracking.
Finalize *::computepass
and *::computecall
to offer the full functionality set as is expected.
At the end we should be able to effortlessly load a "compute" material that outputs to a texture (or other resource), which is then consumed by another "draw" or "compute" material. Preferably this has almost no user interactions needed (i.e. no code to map to one another if everything is described in data files).
This means finding a solution for reference tracked resources (f.e. core::resource::handle), and resources that contain indirections (f.e. std::string). This likely means these resources would need to persist elsewhere in the ecs::state rather than the typical component storage structure, and the storage structure holding indirections to.
Currently we ignore this constraint resulting in being allowed to use these non-conforming elements, and thanks to the way the internal memory storage is handled this is still valid. But as we need to support std::is_trivial
in the future for other ECS features, this should be handled first before proceeding.
Currently the underlying storage knows about the type. This allows us to handle non-trivial types, but disallows us from trivially deserializing these types without knowing the type up front. Ideally we solve this by making the underlying storage itself generic allowing the sidestepping of this problem, and not with type registration patterns.
This issue interacts with #63 and #65 , particularly dealing with complexer types such as reference tracked handles should be considered when solving this problem.
psl::ecs::details::component_info
to utilize this. Preferably figure out a correct way of dealing with flag types that don't incur overhead. Fetching data from this new type should be type-safe (i.e. upper types shouldn't be the one dealing with type safety concerns).Note: we could consider a hybrid system where any serializable component has to use the untyped storage, while serializable components can have non-trivial types.
Following are a list of features that should be investigated or added to the ECS implementation:
Extra:
core::ecs::components::transform
issue in internal docs)When storing a type that has been aligned using alignas
GCC will generate faulty code when fetching the data from a component pack.
example:
struct alignas(16) foo {
float data[4];
};
state_t state{};
state.create<foo>(1);
state.declare([](info_t& info, pack<foo> pack){
for(auto [value] : pack) {
volatile auto copy = value; // <- segfault
}
});
state.tick(std::chrono::duration<float>(1.0f));
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.