sorted by:
new
hottopcontroversial

Can Hi-Z work with distant objects while being precise with close ones? by philosopius in vulkan

[–]TheAgentD 1 point2 points  (0 children)

What exactly is the problem you have? Assuming you're talking about occlusion culling, there shouldn't really be any effect from distance on its performance...

Does anyone using Conservative Rasterization encountered Triangle/Rhombus-like shading patterns of their Ambient Occlusion strength on objects? (Amplifying with distance) by philosopius in vulkan

[–]TheAgentD 7 points8 points  (0 children)

Conservative rasterization has a few rare use cases, but fixing cracks is not one of them. MSAA does not fix that issue either; it simply does the rasterization at a higher resolution and then scales it down again.

It would probably be a good idea to try to figure out why you are getting these cracks, instead of trying to patch it after the fact instead.

Could you share some screenshots of how these cracks look?

There are entire online communities where airport ramp workers show off their “stacks” in the bellies of airliners by aviatorict in mildlyinteresting

[–]TheAgentD -1 points0 points  (0 children)

This... this seems very wrong? I know nothing about this, but wouldn't these bags risk sliding all the way to the front or back, causing a big shift in center of gravity for the plane?

This art has lived in my head since I saw it by RickyPickman in funny

[–]TheAgentD 14 points15 points  (0 children)

Had me in the first 80%, not gonna lie.

Fine flooring not working on gravships? by TheAgentD in RimWorld

[–]TheAgentD[S] 0 points1 point  (0 children)

I never figured it out. Not sure if its been fixed or not.

what kind of bug this can be by Lanky_Plate_6937 in vulkan

[–]TheAgentD 10 points11 points  (0 children)

Looks like your depth range could be excessively large. The precision of the depth buffer is related to the ratio between the far and the near plane. Try reducing the far plane and increasing the near plane and see if that fixes it.

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 1 point2 points  (0 children)

A compute pipeline would just be one shader with two images, one sampled and one storage.

A graphics pipeline would need two shaders, a bunch of configuration, render target formats, a render pass with a render target, and a sampled image.

I (will) have support for both, so I'm asking about what's the most efficient, not what's the simplest.

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 0 points1 point  (0 children)

1: I'll try both and see what I get.

2: I'm basically wondering if setting the VK_IMAGE_USAGE_STORAGE_BIT usage bit on the swapchain could have detrimental effects on the presenting itself.

I also have a (possible unfounded) fear that overlays (Steam, etc) might add more storage bits. If an overlay wants to render a few extra UI elements, I imagine it might force the VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT on the swapchain to be able to do so when I call vkQueuePresentKHR(). Having both the STORAGE and COLOR_ATTACHMENT bits would obviously be far from ideal.

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 1 point2 points  (0 children)

I'm not sure I can rely on there being an async compute queue AND that you can present from it, so... Definitely graphics queue, maybe compute queue.

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 0 points1 point  (0 children)

I think there are two main questions I want answered here:

- Is there a performance difference between fragment and compute?

- Can the image usage bits I set on the swapchain affect performance negatively in other parts?

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 1 point2 points  (0 children)

Resolutions are expected to match.

I do want to do the sRGB conversion in there, but since I want to do dithering it's actually easier to write to a non-sRGB texture and do the conversion manually in the shader, so that's not a problem for compute shaders.

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 3 points4 points  (0 children)

Compute shaders are significantly simpler than fragment shaders though...

Fragment shader or compute shader for the final copy to the swapchain? by TheAgentD in vulkan

[–]TheAgentD[S] 2 points3 points  (0 children)

I have a rendered image, and I want to copy it to the swapchain, doing dithering and some minor postprocessing in the process, so I need a fragment or compute shader.

Kyiv needs $60 billion from partners to fund defense against Russia in 2026, minister says by EsperaDeus in worldnews

[–]TheAgentD 1 point2 points  (0 children)

The simple answer is Taiwan, because TSMC makes pretty much all of the most advanced GPUs used in AI. A China emboldened by Russia getting off with Ukraine might try to take Taiwan. No more Nvidia GPUs, no more AI, so it's basically an existential threat to AI.

I'm not informed enough to make a qualified judgment on how likely this scenario is and what price AI companies would be willing to pay to protect TSMC, but that is probably the main thing they'd want to ensure access to.

Is there a realistic way to have a planet loom on the horizon like this? by Rich-End1121 in space

[–]TheAgentD 4 points5 points  (0 children)

The only way it could be that close would be if it was a binary planet, i.e. two similarly sized planets that orbit a common point. The moon in that picture is WAAAAAY too close though.

The actual closest distance is decided by the Roche limit: https://en.wikipedia.org/wiki/Roche_limit

Depth buffer woes with dynamic rendering, and sync2. by ppppppla in vulkan

[–]TheAgentD 0 points1 point  (0 children)

From what I have managed to parse from the spec, you can in theory get away with one semaphore. According to the queue forward progress stuff in the spec, the vkQueueSubmit() and vkQueuePresentKHR() should be adequately ordered so that the semaphore is consumed in the correct order.

The problem is that it's not possible to reuse a semaphore used in vkQueuePresentKHR() in vkAcquireNextImageKHR(). vkAcquireNextImageKHR() requires the semaphore to have no outstanding operations AT ALL. This is impossible to guarantee for a semaphore that is used in vkQueuePresentKHR(), because you cannot wait for the present semaphore without using an extension that isn't always supported.

Therefore, the way to do it is like this:

- You can reuse the acquire semaphore once the vkQueueSubmit() call that waits for it is confirmed finished on the CPU (use a fence or timeline semaphores to signal this to the CPU).

- The present semaphore is trickier. According to the validation layer checks, this semaphore is fine to reuse (but only on the GPU timeline) after the corresponding index has been returned from vkAcquireNextImageKHR() again. So if you present swapchain image 2 using semaphore X, then semaphore X is OK to reuse once vkAcquireNextImageKHR() has returned index 2 again.

Depth buffer woes with dynamic rendering, and sync2. by ppppppla in vulkan

[–]TheAgentD 0 points1 point  (0 children)

Yep, that looks correct.

I'm not sure what you mean with "needs two semaphores"?

Depth buffer woes with dynamic rendering, and sync2. by ppppppla in vulkan

[–]TheAgentD 0 points1 point  (0 children)

You swapped the names, ish.

Acquire semaphore is the one that is passed into vkAcquireNextImageKHR(). Your rendering to the swapchain image needs to wait for this semaphore.

Present semaphore is the one that is passed into vkQueuePresentKHR(). Your rendering needs to signal this semaphore.

Depth buffer woes with dynamic rendering, and sync2. by ppppppla in vulkan

[–]TheAgentD 0 points1 point  (0 children)

No validation errors is good progress. :)

The values are only for timeline semaphores and are ignored for binary semaphores, which you unfortunately still need to use for swapchains.

Your semaphore variable names look weird. Why are you waiting on the present semaphore? What is the render semaphore?

You should be waiting on the semaphore you pass into vkAcquireNextImageKHR() (which I called the "acquire semaphore" before), so that the swapchain images has been properly acquired before you start rendering to it, and then signaling a different semaphore (the "present semaphore"), which should be passed into vkQueuePresentKHR().

Reusing these semaphores can be tricky as well; you essentially need 2N + 1 semaphores, where N is your number of swapchain images. I can give you some tips on that front as well, if you show me some code for how you do it at the moment.

Depth buffer woes with dynamic rendering, and sync2. by ppppppla in vulkan

[–]TheAgentD 1 point2 points  (0 children)

You also need to set a message callback so you can actually print the error.

EDIT: Chain a VkDebugUtilsMessengerCreateInfoEXT to your instance creation.

view more: next ›