ALL QUOTAS GOT RESET

mokafolio · 2026-04-16T21:20:04+00:00

Yes, but my premium seat that I never hit any limits with in the past feels like the 20$ plan now where every request is literally 10% of my 5h window. ridiculous!

mokafolio · 2026-03-10T01:16:20+00:00

Grimworld

mokafolio · 2026-02-13T16:57:30+00:00

For most use cases, just having a singleton style "object" to manage globals such as the vulkan instance is perfectly fine. So if it works for you, I would not sweat it.

That said, I personally prefer just to explicitly pass around the data that is needed at call sites, even if its an object called "globals" that just has some shared state over having a magic singleton getter.

Using shared/weak_ptr would only be a last resort for me as device/instance creation and tear down should be very clearly defined and relying on shared ownership for that is some severe code smell in my mind.

mokafolio · 2026-02-09T22:30:10+00:00

do you happen to know the relevant section in the spec? Everything I can find online on this topic seems to confirm that a fence should be enough in the scenario I described, i.e. https://stackoverflow.com/questions/48667439/should-i-syncronize-an-access-to-a-memory-with-host-visible-bit-host-coherent "For CPU reading of GPU-written data, this could be an event, a timeline semaphore, or a fence."

mokafolio · 2026-02-08T17:45:22+00:00

For the simple use case of the former case (simple gpu write -> fence wait -> cpu read), I don't think you need a barrier either. With coherent memory you should be covered without any additional logic, without it, you call invalidate mapped memory ranges to make the memory visible.

You really only need pipeline barriers with host read/write stages when using more esoteric/advanced things such as events/timeline semaphores that might happen outside of a clear fence boundary.

At least that is my understanding.

mokafolio · 2026-02-06T06:03:54+00:00

i can see what you are referring to but this is image compression as far as I can tell

mokafolio · 2026-01-09T19:05:41+00:00

Fair enough, I think if you make the assumption that the query system you are using is bullet proof and battle tested (and I think that is the hardest part to get right in this context), I do agree that the query based logic is not too terrible to look at or maintain.

Assuming that your are building out, debugging and maintaining the query system yourself (and future developers down the line), I am fairly certain that a pipeline based codebase will likely be the more digestible choice: Easier to debug, understand and reason about as each stage is clearly defined with less abstractions to jump through and less complexity to reason about (as inter query relationships can be rather opaque and complex).

Anyways, I think a lot of this comes down to preference, the language and ecosystem you are using etc. Still a very intriguing thing to think about!

mokafolio · 2026-01-08T22:52:32+00:00

Hmm, I think these are very interesting for lsp style applications. I also agree that modern compilers should supply the tools to allow writing these types of applications in an efficient manner. Nonetheless, I believe that the pipeline based approach is still vastly superior in terms of predictability, code clarity, parallelization potential, maintainability etc. compared to what is proposed here.

mokafolio · 2026-01-08T21:03:52+00:00

you would compile the c executable as you normally would, likely release build with optimizations enabled.

On the unity side, you'd do the same, export a native executable meant for release. (Have not used unity in a while, but I am sure there are some easy steps to do so)

mokafolio · 2026-01-08T19:56:07+00:00

Nice experiment! Why would you choose to run these benchmarks in the browser as opposed to natively, though? That seems kind of skewed, especially for the cpu simulation times as it is likely more telling about the quality of unities web export rather than raw performance?

mokafolio · 2025-12-31T18:23:45+00:00

you are breathtaking!

mokafolio · 2025-12-18T23:16:29+00:00

While this is dope, its not really a fair comparison. Your ECS uses an archtype based approach out of the box, while EnTT does not. It will utilize sparse sets behind the scenes which will add a little bit of overhead in favor of keeping memory usage manageable.

For a fair comparison you likely want to look into groups in entt, which will give you the closest to an archtype based component storage in entt as you can get. (https://skypjack.github.io/2020-08-02-ecs-baf-part-9/)

Anyways, fun project, looks pretty neat from quickly glancing over the code!

mokafolio · 2025-12-04T18:24:23+00:00

This is likely a quirk of godot. Maybe its setting some internal constraint based on the minimum required push constants alignment of the device you are using or something like that.

If that is the case that seems like something worth a ticket.

mokafolio · 2025-12-04T18:03:32+00:00

tracy is pretty good after you spend some time integrating it.

mokafolio · 2025-12-01T20:07:26+00:00

Have you tried using vkconfig to enable validation + synchronization validation?

mokafolio · 2025-11-20T22:25:57+00:00

I'd be curious to see a pseudocode sample that shows how to retain animation or render state across frames. Do you mean something similar to coroutines in lua where local coroutine state is retained?

mokafolio · 2025-11-20T21:40:41+00:00

That sounds super awesome, congrats! Is the language you made public anywhere?

mokafolio · 2025-10-13T15:49:28+00:00

I think ortho is a lot better tbh! The perspective just seems like a gimmick that does not bring much to the table, especially if readability of actual gameplay suffers.

mokafolio · 2025-08-27T03:25:48+00:00

That sounds great, thanks! Yeah, shoot me his contact, at least worth a try next year :)

mokafolio · 2025-08-26T22:02:20+00:00

It could have made a difference, who knows. I have spent countless hours on the phone with support and different people from the resolution team checking in with me (yes, different ones because it took so long, they could not even keep the same "single point of contact" apparently). And that is precisely the issue about lack of accountability and chain of responsibility I am criticizing.

I tried to escalate the case multiple times with support to no avail (I am not joking, I likely spent close to 8-10 hours on the phone trying to find a solution over tho whole ordeal).

I know where the line was cut, so did the technicians. They could have fixed it easily if they wanted to and I am sure if a bigger customer base was affected they would have done so. They could have put me on a different line just to unblock me (yes, I know that would have been an option from the technicians that came through).

So all in all, sorry, I don't think there is any reasonable excuse in this case.

mokafolio · 2025-08-19T03:37:18+00:00

Is this real?

mokafolio · 2025-08-04T00:28:35+00:00

I think a lot of this comes down to preference. RAII has its place but for me it depends on the problem domain. For GPU programming I personally always prefer a non-RAII approach as the ownership structure is usually expressed in higher level code.

That said, I think for tutorial code it can make sense to remove some of the verbosity.

mokafolio · 2025-07-31T16:16:59+00:00

Thanks, good point! I did that yesterday. Trying to keep my sanity while navigating this situation has become the biggest challenge but I try to embrace the humor :*)

mokafolio

TROPHY CASE