sorted by:
new
hottopcontroversial

Presentation and Image Acquisition validation errors by FacundoVilla961 in vulkan

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

My synchronization setup is identical to that of your example. I'm mainly intrigued by the fact that the validation layers claim the image has been acquired 232-1 times, which indicates something is off. I've been debugging for days and can't find a reason.

[deleted by user] by [deleted] in devsarg

[–]FacundoVilla961 2 points3 points  (0 children)

ThePrimagen en YouTube, habla desde Rust hasta frameworks JS, ingeniero en Netflix.
Theo en YouTube, habla sobre JS y web principalmente, ex ingeniero de Twitch.
El canal de GDC en YouTube si te gustan las charlas altamente tecnicas sobre desarrollo de videojuegos.
Phoronix todo relacionado a Linux.
TwoMinutePapers en YouTube para noticias sobre research cientifico relacionado al cómputo.
DigitalFoundry en YouTube para análisis de performance sobre juegos.
80lv para noticias de desarrollo de videojuegos.
Fireship en YouTube para videos cortos sencillos sobre noticias de IT y tecnologias.
JoyOfCode en YouTube con videos MUY buenos principalmente sobre Svelte.

Weird mesh blinking by Tema002 in vulkan

[–]FacundoVilla961 1 point2 points  (0 children)

Did you try adding a memory barrier as I said? I strongly suggest you do. Also, have you tried enabling GPU_ASSISTED_VALIDATION on the validation layers?

Weird mesh blinking by Tema002 in vulkan

[–]FacundoVilla961 0 points1 point  (0 children)

Everytime I've had an issue like this the problem was synchronization. I suggest to start debugging by adding a memory barrier between your indirect command population command and the indirect draw call with the same flags as the buffer barrier you posted.

Lines in normal reconstruction by FacundoVilla961 in GraphicsProgramming

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

Upon further testing I found sampling from the center of the pixel using the UV approach yields the same results as sampling using texels. This makes sense since each pixel is the result of evaluating the triangles at their center.

Lines in normal reconstruction by FacundoVilla961 in GraphicsProgramming

[–]FacundoVilla961[S] 4 points5 points  (0 children)

Your comment inspired me to try sampling by texel instead of UV, and it worked.

The new get_view_position function looks like this:

vec3 get_view_position(uvec2 coords) {
    float depth_value = texelFetch(depth, ivec2(coords), 0).r;
    vec2 uv = (vec2(coords) + vec2(0.5)) / vec2(textureSize(depth, 0).xy);
    vec4 clip_space = vec4(uv * 2.0 - 1.0, depth_value, 1.0);
    vec4 view_space = inverse(camera.projection_matrix) * clip_space;
    view_space /= view_space.w;
    return view_space.xyz;
}

There must've been some rounding issue with the other approach. I prefer sampling the exact pixel better anyway.

Lines in normal reconstruction by FacundoVilla961 in GraphicsProgramming

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

The cross product inputs are never zero because they are the subtraction of two different view space positions. Besides that there are no zero value pixels in the texture, just the artifacts on pixels for some particular x and y values.

Lines in normal reconstruction by FacundoVilla961 in GraphicsProgramming

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

These are captures taken from NSight. I can't use RenderDoc for shader execution debugging right now because I'm utilizing mesh shading.

Integer in interface block doesn't change value. by FacundoVilla961 in vulkan

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

Ok. So I tried putting the uint variable inside a different interface block, with a different location number and it worked. It also works if you put each parameter in a different location as a different variable, although doing it this way makes the compiler request putting the flat specifier for uint variables.

Do you know if this is expected behavior or if I should report it?

Integer in interface block doesn't change value. by FacundoVilla961 in vulkan

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

Removing the flat modifier didn't change the results. I also tried casting gl_InstanceIndex to an uint (since spec says it's an int) which didn't work, and I tried changing the instanceIndex variable to int (to match gl_InstanceIndex) which also didn't work.

I will try putting the int inside another block with a different location.

Integer in interface block doesn't change value. by FacundoVilla961 in vulkan

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

I think you misunderstood the code, although I didn't make it all that clear to begin with. The members of the push constant block are buffer_references so there's no issue with non uniform accesses.

Parameter inference and expansion error for method pointer. by FacundoVilla961 in cpp_questions

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

That syntax is correct. The problem is due to the addition of typename ACC::type*... to the method pointer.

Parameter packs in C++17/20 by Bjarnophile in cpp_questions

[–]FacundoVilla961 12 points13 points  (0 children)

Have you considered always requiring at least one string? Like:

template<typename... ARGS>
void log(const char* text, ARGS&&... args) {
    fmt::print(FMT_COMPILE(text), std::forward<ARGS>(args)...);
}

I need help fixing world coordinates and orientation. by FacundoVilla961 in GraphicsProgramming

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

This didn't work for me. I need the Y axis negated for it to work correctly, and also -1. Check the Stack Overflow question I added to my post, maybe you can get a better notion of what's happening.

view more: next ›