|
Xerophyte posted:This lead me down a rabbit hole of looking at the subgroup stuff from 1.1 which I was completely unaware existed; I'm not very current or good with GPU framework stuff which is why I started this litte hobby project. Thanks! I noticed that the 1 atomic/subgroup was exactly what the subgroup tutorial recommends too. I expect the subgroup operations will be very useful for stuff like sampling, since I can make the subgroup collectively vote on the BRDF to sample which should be efficient. Unfortunately I don't think I can boil down path tracing sample accumulation to scan local group + one atomic op in that way. Incoherent gathers are, all else being equal, going to be way faster than incoherent scatter in part because the GPU is built to handle them as a common case. Ralith posted:If the target locations are effectively random, contention might not be too big an issue, though I suppose that's scene dependent. Actually, having threads from the same subgroup hitting the same global atomic is ironically probably going to be faster, because you can coalesce the atomic within a warp (essentially as a parallel sum) and then do a single write to the global address. Atomic contention within a thread group can add latency to the thread group; atomic contention between different thread groups can potentially serialize the entire machine.
|
# ? Nov 3, 2020 13:46 |
|
|
# ? May 4, 2024 12:57 |
|
Hubis posted:Actually, having threads from the same subgroup hitting the same global atomic is ironically probably going to be faster, because you can coalesce the atomic within a warp (essentially as a parallel sum) and then do a single write to the global address. At least Intel doesn't do this; explicit subgroup ops made a shader of mine an order of magnitude faster.
|
# ? Nov 3, 2020 18:38 |
|
Not really a 3d question but this is probably the right place to ask this question. I'm trying to encode a series of IDXGISurfaces with an IMFSinkWriter. Here's my encoder implementation:code:
code:
For some context - my end goal is to encode an IddCx virtual display which has SwapChain that supplies the IDXGISurface. Since developing and debugging drivers is painful at best I want to prove out my encoder on a simple desktop app. Since I have 0 experience with DirectX I found a tutorial here which uses a SwapChain on a desktop app and added a call to my Encoder::AddFrame. I was able to save the contents of the IDXGISurface without any issue so I know things are working at some level. Edit: If I create the buffer with a static block of memory like this example things work fine so it's something to do with the surface I'm trying to use. fankey fucked around with this message at 05:12 on Nov 10, 2020 |
# ? Nov 10, 2020 05:01 |
|
Hey, got a question about OpenGL VBOs and using indexed glDrawElements[BaseVertex], with non-interleaved attributes. So let's say I'm rendering a cube: 8 vertices, 6 faces, 12 tris. Forget about triangle strips for the moment and lets say I'm using basic GL_TRIANGLES, so there would be 12*3 = 36 vertex indices. I have a shader which takes a vertex attribute relating to how edges are rendered: eg "internal" edges of cube faces would be omitted. I want to avoid duplication of vertex coordinate data, but each vertex of the cube could be used in anywhere from 3 up to 6 triangles (or 4.5 on avg), and I would want that vertex attribute to possibly be different in each case. Since the attributes are not interleaved, is there any way to have them indexed separately from the vertices? As I understand, you can set up the initial location and stride with glVertexAttribPointer, but how does that work with indexed elements? Is it always going to basically follow vertex_index * attribute_stride when accessing these attributes even from separate buffers, or can it be made to just sequentially/directly go through that attribute buffer, while indexing the vertices indirectly?
|
# ? Nov 29, 2020 13:27 |
|
peepsalot posted:Since the attributes are not interleaved, is there any way to have them indexed separately from the vertices? There is not, but you can always use a storage buffer instead of a vertex attribute, and index it with whatever logic you like.
|
# ? Nov 30, 2020 06:36 |
|
I am struggling with this shader here: Perlin Noise Shader I'd like it so that regardless the dimensions of the plane it is on, it will properly display the generated noise, instead of stretching or squashing. Can I get this to use world coordinates instead of vertex coordinates?
|
# ? Jan 1, 2021 02:24 |
|
Not entirely sure that what you're asking for is what you want. Sure, you can do simplex/FBM noise in worldspace. Exactly how you do it in Unity I don't know. I'd guess that they have easier methods than editing that shader, but I don't know Unity. Anyhow, that repo has a 3D version at https://github.com/Scrawk/GPU-GEMS-Improved-Perlin-Noise/blob/master/Assets/ImprovedPerlinNoise/Shader/ImprovedPerlinNoise3D.shader which is probably a better base. The only change you'd need to do is at the call point. At fBm(i.uv.xyz, 4);, use the worldspace position instead of the 3D UV. It should just work. If your UVs have a consistent scale across the entire surface then another option is to keep using the 2D version but add a real world UV scale parameter to the shader (also works if your surface is a plane, in which case you can just project its worldspace coordinates). This is how basically every CAD material works: all the meshes have a consistent UV scale known by the application. All the textures, including simplex noise and other procedurals, have metadata specifying the real-world extent of a [0,1] slice. Those two values are used to compute a float2 texture scale that is applied to the UVs when rendering. I'd also note that shader is implementing a GPU Gems article by Ken Perlin from 2004 that focused largely on performance. Ken Perlin is, unsurprisingly, pretty good at Perlin noise so it's going to work fine. It also does a lot of things that aren't relevant 16 years of GPUs later.
|
# ? Jan 1, 2021 19:37 |
|
Basically I just want to (in Unity) generate procedural Perlin/Simplex noise to a texture to use for real-time terrain generation (I tried using DOTS/Unity's Jobs system but 5k by 2k was an unacceptable 10 seconds). In Unity you use Graphics.Blit, which at first didn't work very well but eventually some people were able to help me solve it. Changing it from code:
code:
To from there get it so that the displayed material on the plane doesn't squash/stretch when I change the scale of the plane to something that isn't square (1408, 1, 512) I did this: code:
Where _Scale is something like 2.75, 1 in the case of 1408 by 512 to make sure the noise/material displayed to the plane isn't being stretched. But now I want to be able to both zoom and pan (zoom is controlled by _Frequency), but I can't get that to work. If I put the Offsets in inoise it pans and stays centered but has a weird parallax/cloud effect. code:
code:
code:
I don't really need 3D or 4D noise because I'm likely just going to use a fall off map to insure the map is surrounded by water, so I don't really need it to be able to wrap around. I can probably live with the parallax but if there's a simple change to fix it, I'd be greatful.
|
# ? Jan 1, 2021 21:01 |
|
Raenir Salazar posted:Basically I just want to (in Unity) generate procedural Perlin/Simplex noise to a texture to use for real-time terrain generation (I tried using DOTS/Unity's Jobs system but 5k by 2k was an unacceptable 10 seconds). Right, OK. I'm kind of avoiding doing a deep dive into that particular simplex noise implementation, because it should be irrelevant to your problem and it seems very Unity-specific. I would again be deeply surprised if Unity does not have a better solution to your problem than "edit this shader" but I don't know Unity. Someone who does could probably give a better answer. This said, the "parallax" you're talking about sounds like what happens when you scale or translate the different octaves in simplex noise independently. I think inoise is called for each octave in that implementation, so if you insert a fixed transform there then the transforms will only be correct for at most one octave of the noise and you get the effect that the different layers of the noise move independently. For texture transforms, you're on the right track by the sounds of it. You can always do those without touching anything about the details of the texture generation or even knowing what type of texture you are using. You don't need or want to touch noise generation parameters like frequency or bandwidth to zoom or pan, any more than you'd need to edit an image-based texture in paint to zoom or pan. If you have a texture coordinate p, and you want to translate it so the texture origin is centered on a point p0, you can do the transform p = p + p0. If you want to zoom in by a factor of k, you can do the transform p = p * k. Transforming the texture lookup coordinate prior to look-up works for any texture, procedural or image, of any dimensions. So just do that things wherever you're specifying the o.uv = v.texcoord - float4(0.5, 0.5, 0, 0); texture coordinate, I assume the vertex shader. You'd end up with something like: code:
I suggested 3D noise because I figured you were texturing 3D data. I'm not sure what you mean by wrap-around, but it sounds unrelated to texture dimension. Since you're texturing a 2D image, use a 2D texture.
|
# ? Jan 4, 2021 23:23 |
|
Xerophyte posted:Right, OK. I'm kind of avoiding doing a deep dive into that particular simplex noise implementation, because it should be irrelevant to your problem and it seems very Unity-specific. I would again be deeply surprised if Unity does not have a better solution to your problem than "edit this shader" but I don't know Unity. Someone who does could probably give a better answer. Thanks for this! I was able to gradually solve it with some help in the Unity discord, so for reference I will document the solution for your interest Unity doesn't really have any better noise generation solution that's real time. I tried using their noise generation function from their math library in DOTS (their multithreading/jobs API) and it was still 10 seconds or more for a 5k by 2k texture while this github project was real time on the shader. Basically it seemed like it was an unavoidable issue where the snoise(...) function was a very expensive operation no matter what when performed on the CPU with the in-built Unity one. Maybe one of those "fastnoise" libraries would've made it better but they use generators and would've required a way to re-implement it to work while multithreaded. The solution in the end looks like this: code:
code:
code:
code:
I figure it's much faster to blend textures on the GPU and re-Blit the result to a new texture than to either use multithreading to apply photoshop blends or just to run a loop. Not that running a loop would've been slow, as it was the noise function that made it intolerably slow. Although I hated the streaks on the diagonals, so after discovering Unity's Shader Forge has a Rounded Rectangle node, spent some time through sheer trial and error reimplementing it as a custom node. code:
I then plug the resulting value into another custom function node that takes the value to a power of a different a,b input to adjust the fall off map. Basically I wanted to have the "fall off" of the fall off map but in the shape of a rectangle, the "linear" based fall off map resulted in uglyness along the diagonals, if I knew how to do like, bicubic sampling or gaussian blur maybe that would've fixed it but it seemed easier to reimplement the rounded rectangle. code:
Since by multiplying ridged noise and fbm noise will give like, mountainous looking islands with ridges and so on. I've tested it and the results are Blit-able back to texture, so I'm pretty happy that I can get the results I want. I'm basically working on a procedural random world generator where I'd like to give the user/player the ability to create a world as they want.
|
# ? Jan 5, 2021 18:21 |
|
I'm trying to write a simple HLSL 2d shader ( the end result is a WPF Effect if that matters ) that needs to deal with alpha and I am getting totally confused. This simple filter works fine and passes the color straight throughcode:
code:
code:
I tried saving the alpha and reapplying but it didn't make any difference.
|
# ? Jun 15, 2021 18:28 |
|
fankey posted:I'm trying to write a simple HLSL 2d shader ( the end result is a WPF Effect if that matters ) that needs to deal with alpha and I am getting totally confused. This simple filter works fine and passes the color straight through Have you tried dividing the color by the alpha, inverting, then multiplying by the alpha? It might be pre-multiplied and get messed up if you don't account for it.
|
# ? Jun 15, 2021 18:32 |
|
Also are you sure the range of the texture channel values is 0-1? If the texture uses an integer pixel format it could be 0-255 and casting it to float won't necessarily normalize it. What happens if you assign 1.0 to red in the second example?
|
# ? Jun 15, 2021 18:37 |
|
Absurd Alhazred posted:Have you tried dividing the color by the alpha, inverting, then multiplying by the alpha? It might be pre-multiplied and get messed up if you don't account for it.
|
# ? Jun 15, 2021 19:12 |
|
How can I calculate if a planar polygon in 3d space is front or rear facing in relation to the camera? I need to apply a glPolygonOffset in opposite direction depending on which side is visible.
|
# ? Aug 11, 2021 20:30 |
|
If you're using the fixed function pipeline, GL can do this for you with with the cull options. Then you just render it twice, for front and back, with matching offset values If you're in a shader, check the sign of normal.z after the modelview transformation
|
# ? Aug 11, 2021 20:52 |
|
You can apply an offset to gl_FragDepth based on gl_FrontFacing in the fragment shader. That might limit the early z tests, depending on how you're offsetting, and I don't think you can offset by the same amount as glPolygonOffset (which I've never used). In general you will not be able to do this in the vertex shader by just looking at the post-transform normal. A given vertex can be a part of both a front-facing and a back-facing triangle, and a vertex normal can and almost certainly will be back-facing from some perspectives even if it is a part of a front-facing triangle. Offsetting the vertex by the normal still works if you know you have nice inputs with vertex data that lets you, of course, but not for arbitrary input.
|
# ? Aug 11, 2021 21:25 |
|
Kind of a long shot. Does anyone know how the Material Graph in Unreal Engine works? I’m assuming a graph gets "cooked" into a shader + textures but I can’t seem to find where in the code this happens. For example in another engine I know that has a much less sophisticated material graph each node actually corresponds to a "template" (for lack of a better term) of shader code and when the graph gets cooked for release it just compiles together each node into a single shader text file and then compiles that to spirv or whatever platform shader byte code. In other words each node is just some text and it walks the graph and concats the text together (albeit it’s a bit more complicated then that). But this doesn’t appear to be how Unreal does it. EDIT: Was able to find what I was looking for in: - Source/Runtime/Engine/Private/Materials - Shaders/Private/MaterialTemplate.ush xgalaxy fucked around with this message at 17:05 on May 25, 2022 |
# ? May 25, 2022 01:56 |
|
If I’m planning to do cross-platform 3d graphics, is there any reason not to do it in Vulkan? I.e., is there any advantage to the alternative of manually doing a dx12 backend and a metal backend? (Talking mostly theoretically here just to better understand. I’m probably gonna just stick with OpenGL for my actual work for the foreseeable future)
|
# ? Aug 31, 2022 17:05 |
|
giogadi posted:If I’m planning to do cross-platform 3d graphics, is there any reason not to do it in Vulkan? I.e., is there any advantage to the alternative of manually doing a dx12 backend and a metal backend? My impression is that structurally there isn't that much difference between the latest generation of APIs. That being said, you might still not be able to use Vulkan or might not have as much support for some low-end or specialized platforms like slightly older consoles and maybe certain smartphones. So you might end up having to create an abstraction layer with separate implementations anyway.
|
# ? Aug 31, 2022 18:51 |
|
I'm following vulkan-tutorial.com on an old mac with integrated graphics. I ran into a weird issue, and I wonder if any of y'all have a clue about what could be going on. The first part of the tutorial involves drawing a single triangle to the screen without using a vertex buffer at all, so the vertex shader just hardcodes the vertex positions and colors into the shader, using gl_VertexIndex to select the appropriate position/color. I'm following the code exactly to the tutorial, but my triangle's colors are wrong: only one corner is red, and the other two corners are black. code:
code:
code:
e: I realize that this specific shader is totally unrealistic, but I'm stuck on this because in the future if I want to use hardcoded constant arrays for some reason, I'm not gonna trust 'em if they can exhibit weird behavior I don't understand!!! giogadi fucked around with this message at 22:09 on Nov 20, 2022 |
# ? Nov 20, 2022 22:04 |
|
Is your code validation clean? Wouldn't be shocked if you're hitting a moltenvk or driver bug, "old integrated Mac" is almost the worst environment you could've chosen. It's also not really an unrealistic shader at all, most games do something similar for full screen passes. Ralith fucked around with this message at 23:49 on Nov 23, 2022 |
# ? Nov 23, 2022 23:42 |
|
Suppose I have a compute shader with a really sparse SSBO array that is ostensibly a tree structure that fills itself up (fixed depth, fixed size). Is it fine to just no-op any indexes that haven't been populated yet? Edit: Found better leverage of my acceleration structure to still do everything parallel but get 90% of the benefit. Still posing the question whether a single if-then-no-op is potentially slow just because it needs to split the execution weirdly or something. Ranzear fucked around with this message at 01:41 on Mar 20, 2023 |
# ? Mar 15, 2023 22:22 |
|
giogadi posted:I'm following vulkan-tutorial.com on an old mac with integrated graphics. I ran into a weird issue, and I wonder if any of y'all have a clue about what could be going on. Ranzear posted:Suppose I have a compute shader with a really sparse SSBO array that is ostensibly a tree structure that fills itself up (fixed depth, fixed size). Is it fine to just no-op any indexes that haven't been populated yet? If you mean something like: code:
It'll really depend on how much work is done on that branch. If it's really quick then it's probably not a big deal but if it's long then you could be hurting your utilization over time. Note that if you have an else branch on that it gets even worse because all the threads in each warp will have to run both if even one is different
|
# ? Apr 15, 2023 19:59 |
|
VostokProgram posted:This could very well be a compiler bug. Can you post the SPIR-V? The Vulkan sdk has a program called spirv-dis you can use to get a text listing of a SPIR-V binary. I'm not familiar with Mac development but I assume you're using glslang to convert from GLSL to SPIR-V right? A little while back I actually found a github issue on MoltenVK with my exact problem: https://github.com/KhronosGroup/MoltenVK/issues/1499 It looks like it's a bug in Intel's Metal drivers. I've been meaning to put together a super minimal example in pure Metal that reproduces the issue that I can send over to Apple. It really sucks that bugs like this exist - it makes me afraid to use any graphics API built on top of Metal because it could potentially have weird bugs like the above. It's shameful that support for intel-based macs is so bad - there are still soooo many of these macbooks out there that otherwise work really great!
|
# ? May 5, 2023 16:28 |
|
giogadi posted:A little while back I actually found a github issue on MoltenVK with my exact problem: Tbf any API might have bugs, that's just the nature of software. I've seen stuff like this in OpenGL too.
|
# ? May 5, 2023 20:52 |
|
I'd go further and say every API absolutely has bugs. Right now.
|
# ? May 6, 2023 00:37 |
|
Has anyone here actually used mesh shaders in production? Did you have a problem for which you felt they were the best option? I'm curious because they've been around a while and the only game I've heard uses them is Alan Wake 2
|
# ? Mar 18, 2024 18:17 |
|
|
# ? May 4, 2024 12:57 |
|
I think they're still not widely supported, so if you use them it can only be as an optional extra, which makes it a harder sell.
|
# ? Mar 19, 2024 18:29 |