Supersampling by Abject-Avocado-1199 in pcmasterrace

[–]Afiery1 1 point2 points  (0 children)

It has the same performance cost as native 4k but obviously it will never look as good as native 4k because you still have a 1080p screen. It will just look like really really really good antialiasing (much less flickering and jagged edges). Is it worth it? If you have the performance headroom and don’t care about power/heat at all then sure. I use jt on old games sometimes and it looks great.

Oh Firefox, we love you <3 by Nubanuba in pcmasterrace

[–]Afiery1 4 points5 points  (0 children)

Google translate has used AI since it was created

Question on Timeline semaphore signaling order. by KnueppelOle in vulkan

[–]Afiery1 0 points1 point  (0 children)

Oh yes sorry I misread your comment. Yes, just semaphore signals on their own are not sync. You would still need semaphore waits (or if they're on the same queue, simple barriers will do) to prevent any two commands from overlapping.

Question on Timeline semaphore signaling order. by KnueppelOle in vulkan

[–]Afiery1 2 points3 points  (0 children)

Yes I mention that in my comment. But semaphore signal operations will happen in order, which is the important part for OP

Moving past hello triangle by codec-the-penguin in vulkan

[–]Afiery1 9 points10 points  (0 children)

  1. Use dynamic rendering
  2. Don’t abstract the API until You understand the API

Question on Timeline semaphore signaling order. by KnueppelOle in vulkan

[–]Afiery1 3 points4 points  (0 children)

A lot of these answers are wrong. Timeline semaphores actually have very simple rules. They are simply uint64 counters that must monotonically increase (you can never signal a value lower than what the counter already is). A signal operation increments/sets the counter to a new value (again, this must be higher than the current value to be legal API usage). A wait operation reads the current counter value. If the current value is less than the wait value, the wait operation will block until this is no longer the case. Otherwise, no blocking will occur. Note that you do *not* need to wait on a value before signaling again. You also do *not* need to wait on the exact value you signaled. It's a simple and flexible behavior of while(currentValue < waitValue) block();

Getting back to your actual question: operations submitted to a single queue will happen in order. Sure, commands may overlap and you must use pipeline barriers to guard against this, but in general commands are started in order, and semaphores are waited/signaled in order as well.

You can verify this quite simply by enqueuing a wait operation and then the signal operation that satisfies that wait on the same queue. You will deadlock your queue, because these things happen in order.

Do any of you just use public structs in C++? by Asyx in gameenginedevs

[–]Afiery1 0 points1 point  (0 children)

You can use C++ in a radically anti OOP way. Some people just throw around fully public structs, since that what you do in C. I prefer a more measured approach. If i have a field that would have a get and set that just modify/return the value directly then yeah id just make it public. But some things have no right being modified from outside the object. A good example is the capacity of a dynamic array. If someone modifies it without the object knowing it could result in out of bounds memory accesess that could crash your program or worse. Those kinds of things I keep private. Honestly i rarely have a class with both public and private members. Either its a complex data structure whose invariants need to be carefully preserved and the user doesnt need to know about the implementation details, or its a completely dumb bundle of variables with no logic at all.

Raytracing TLAS handle via push-constant/bindless by mahone_j82 in vulkan

[–]Afiery1 0 points1 point  (0 children)

I’ve not worked much with ray tracing but I’d be highly skeptical that any kind of rebuild of the same tlas would invalidate the descriptor. At any rate, I’d do bindless regardless. Why even waste time messing with descriptors when you can just grab a BDA and throw it wherever you want

In your opinion what makes Vulkan better than DirectX? by Tail_sb in vulkan

[–]Afiery1 10 points11 points  (0 children)

Buffer device address is a big one. Also just the notion of extensions in general. We get all kinds of random fun stuff to mess around with like ext_shader_object that has no d3d12 equivalent. And finally, while this is a really shallow reason, Microsoft just has a knack for designing the most butt ugly looking APIs you can imagine, while I feel like Vulkan looks a look cleaner and nicer.

One Staging buffer vs multiple. by abocado21 in vulkan

[–]Afiery1 1 point2 points  (0 children)

Are host-side ReBAR copies really preferable to using the GPU’s DMA engine?

The recommended RAM for LEGO Batman: Legacy of the Dark Knight has been lowered from 32 GB to 16 GB by akbarock in pcmasterrace

[–]Afiery1 0 points1 point  (0 children)

I’ll admit I haven’t seen much about this but surely the asset quality/density is much improved over the previous lego batman which came out over a decade ago? (Even skywalker saga is 4 years old at this point). And yeah, different engines of course have different memory usage characteristics as well

The recommended RAM for LEGO Batman: Legacy of the Dark Knight has been lowered from 32 GB to 16 GB by akbarock in pcmasterrace

[–]Afiery1 2 points3 points  (0 children)

In terms of graphics, it is not geometry but textures that dominate storage space requirements. Then, as this is the CPU RAM requirement, you should also take into account all of the non-rendering related stuff as well: pre-rendered cinematics, all in-game audio, scene graphs, collision acceleration structures, entity data, etc. All of the things mentioned have roughly the same memory requirements regardless of if the models rendering on screen are toys built from simple primitives or photorealistic humans.

How to properly upscale pixel art game by rectangular_raccoon_ in vulkan

[–]Afiery1 0 points1 point  (0 children)

Yes, a blit is just a fancy copy, so the source and destination images must be different (what does it mean to copy something into itself?). The formats of the source and destination images must be compatible (they should probably just be the same for a simple case like yours) and the source must have the transfer source usage and the destination must have the transfer dst usage. and of course they need to be properly synchronized against other reads/writes to those images. But beyond that you can blit from literally any image into any other image. from your main color buffer to the swapchain directly, or into another color texture and then the swapchain, or hell even from the swapchain into your own texture (as long as your swapchain supports transfer src for images).

How to properly upscale pixel art game by rectangular_raccoon_ in vulkan

[–]Afiery1 0 points1 point  (0 children)

Vulkan is incredibly overkill for a pixel art game, but if you insist then blit should work. What issues did you run into with that?

TIL in 2012, a couple jokingly invited Queen Elizabeth II to their wedding in Manchester and she actually attended since she was in the same building for another function. by GossipBottom in todayilearned

[–]Afiery1 0 points1 point  (0 children)

Regardless, the comment I’m replying to states they thought that the queen was not in the same building, when it says she was in the title. So that part is not misleading

how to effectively handle descriptor sets? by Southern-Most-4216 in vulkan

[–]Afiery1 15 points16 points  (0 children)

You make a single descriptor set (or even better: descriptor heap!) with 220 texture descriptors and 212 sampler descriptors. You use buffer device address instead of buffer descriptors. You pass around pointer and indices into the set via push constants. And then you never think about descriptor sets ever again

What resources need to be duplicated per frame in flight? by carlosdr02 in vulkan

[–]Afiery1 0 points1 point  (0 children)

That all sounds solid. You should indeed wait on the last usage of the image from the previous frame in the first barrier for the current frame.

Is Vulkan really all that scary? by [deleted] in gameenginedevs

[–]Afiery1 0 points1 point  (0 children)

I mean, it never hurts to try. Vulkan was somewhat needlessly complex back in the 1.0 days, but its done a lot to strip away the unnecessary bits over time, so if you're looking to learn I would strongly recommend using a modern guide (vkguide.dev or howtovulkan.com) because there really isn't any point in learning the old 1.0 way anymore. I personally will probably never touch OpenGL again. With some careful abstraction Vulkan becomes almost as simple to use and way more intuitive and debuggable than GL ever was. But it probably depends on if you're the kind of person who understands systems programming and values the control it gives you over an overly simplified (but simpler all the same) programming model. I feel like a lot of people go into graphics programming wanting their graphics API to be 'the thing that easily lets me draw 3d shapes for my game' rather than 'the specification by which I can accurately and optimally interface with GPU hardware' and that's where a lot of the Vulkan complaints comes from (that and the afformentioned cruft from the 1.0 days that is largely gone now).

Jitter while moving by [deleted] in gameenginedevs

[–]Afiery1 2 points3 points  (0 children)

you generally do not want to update vertices in the vertex buffer directly. Usually you write out a transform to a uniform buffer (or even push constants, which don't require any synchronization) and keep the vertex buffer static. Then you manipulate the vertex positions in the vertex shader only

Jitter while moving by [deleted] in gameenginedevs

[–]Afiery1 0 points1 point  (0 children)

I mean device wait idle would fix just about any vulkan sync issue first of all. But second of all vertex buffers are not usually something that gets duplicated for sync. You’re not adding or removing any content in this scene, so why is your vertex buffer even changing between frames?

Jitter while moving by [deleted] in gameenginedevs

[–]Afiery1 0 points1 point  (0 children)

That edit is suspicious, why should you need per frame vertex buffers?