[gui] GGUI 3/n: Add dependencies, interfaces, and backend-independent code #2650
Conversation
AmesingFlank
requested review from
bobcao3 and
k-ye
and removed request for
bobcao3 and
k-ye
|
We will have a solution extremely soon through the unified device backend &
memory allocator.
…On Mon, Aug 9, 2021, 11:18 PM Dunfan Lu ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In taichi/ui/common/field_info.h
<#2650 (comment)>:
> @@ -0,0 +1,31 @@
+#pragma once
+#include "taichi/ui/utils/utils.h"
+
+#include "taichi/ir/type_utils.h"
+
+TI_UI_NAMESPACE_BEGIN
+
+enum class FieldSource : int {
+ TaichiCuda = 0,
+ TaichiX64 = 1
+ // support np array / torch tensor in the future?
Well yes. But right now there's no API to expose the corresponding buffer
for those backends. For LLVM backends，we have ti.get_addr. I think we
should start working on a more systematic way of interop-ing once we have
SNode Descriptors ready.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#2650 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7Q5G2EAEI6DPX52S4533T4DAC7ANCNFSM5BZVKGTQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
At that scale we can do stochastic transparency. No need to sort them. Or,
we can also do a radix sort, should be fast enough to work on a scale of
1e6.
(I'd prefer stochastic transparency tho)
…On Mon, Aug 9, 2021, 11:24 PM Dunfan Lu ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In taichi/ui/common/scene_base.h
<#2650 (comment)>:
> +
+struct PointLight {
+ glm::vec3 pos;
+ glm::vec3 color;
+};
+
+struct MeshInfo {
+ RenderableInfo renderable_info;
+ glm::vec3 color;
+ float shininess;
+};
+
+struct ParticlesInfo {
+ RenderableInfo renderable_info;
+ glm::vec3 color;
+ float radius;
Billboard particles. And for RGBA, IIUC we'll have to sort the particles?
I’m not sure if we can do it fast enough. In PIC/FLIP simulations etc we
can get to ~1e6 particles.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#2650 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7Q5CPHY4ASWGIXWUDHVDT4DAZJANCNFSM5BZVKGTQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
Nice. In that case I'll at least add Vk and GL backends into this enum. |
I remember that on my geforce 1060 laptop, in a ~20fps particles simulation, radix sort using nvidia thrust costs 1% of the entire cost. And re stochastic transparency, sadly i don't know anything about it. I’ll leave it as RGB for now and we can add transparency in the future. |
https://luebke.us/publications/StochasticTransparency_I3D2010.pdf Pretty much all modern games use this to avoid sorting. (Or with a very minimal sorting through binning) |
Related issue = #2646
This is the 3rd of a series of PRs that adds a GPU-based GUI to taichi. This PR adds dependencies (dear imgui and glm), APIs, and all the non-vulkan-related code.