L. Spiro

Vulkan Vulkan Resources

Recommended Posts

InvalidPointer    1842

FYI the AMD drivers are partially broken, at least on my 290X. There's something wrong with their ICD implementation, there are posts on the internal AMD developer forum about the issue.

 

EDIT: Never mind. I went to go check on the status of this and it looks like AMD has issued a hotfix.

Edited by InvalidPointer

Share this post


Link to post
Share on other sites
Dingleberry    924


https://github.com/SaschaWillems/Vulkan

 

Is it just me or are most of the samples doing a ton of unnecessary waiting? 

 

With the exception maybe doing something quick and dirty, special blocking loads, or maybe something fancy I can't think of at the moment, I kind of assume one wouldn't want to call vkDeviceWaitIdle or vkQueueWaitIdle very frequently. Right? But they seem littered everywhere.

Share this post


Link to post
Share on other sites
Klutzershy    1681

Is it just me or are most of the samples doing a ton of unnecessary waiting? 

 

With the exception maybe doing something quick and dirty, special blocking loads, or maybe something fancy I can't think of at the moment, I kind of assume one wouldn't want to call vkDeviceWaitIdle or vkQueueWaitIdle very frequently. Right? But they seem littered everywhere.

 

It's a hell of a lot easier than setting up the infrastructure for double (or more) buffering, where you need to ensure that you don't change/delete things that are being used for the previous frame.  You still need to issue a wait every 2 frames for double buffering (3 for triple buffering, and so on), but in practice, it's just there as a safeguard for pathological scenarios and should typically be a no-op.

Share this post


Link to post
Share on other sites
Madolite    393

I'm kinda excited for it, but with my limited openGL experience I'll be sticking with openGL for now. Definitely coming back to this in the future though, to learn more about those extra control goodies.

Share this post


Link to post
Share on other sites
Dingleberry    924

I'm kinda excited for it, but with my limited openGL experience I'll be sticking with openGL for now. Definitely coming back to this in the future though, to learn more about those extra control goodies.

There's very little that looks anything like GL. It looks a whole lot like DX12 however.

Share this post


Link to post
Share on other sites
_the_phantom_    11250
Just as a heads up; Khronos have a couple of low-resolution versions of the GDC presentations up on youtube, while the slides are readable it is currently suffering from some horrible audio drop out (around the 1 hour mark you basically can't hear anything), which is not overly helpful when it comes to trying to hear about memory allocation.

I'm hoping it'll be fixed in the high resolution version, but I'm not holding out any hopes... (see comment in other thread about half-arsing things).

Share this post


Link to post
Share on other sites
vlj    1070

Does Android emulator support Vulkan on Windows ? Or do I need a Vulkan ready Android device to develop ?

Share this post


Link to post
Share on other sites
vlj    1070

Is there a sampled showing input_attachment usage ? I'm trying to use them but so far it doesn't work (subpassLoad() always returns 0 and there is no debug layer message related to the issue) so I'd like to see a working example.

Share this post


Link to post
Share on other sites
vlj    1070

I forgot to fill more than one attachment in vkPipelineColorBlendStateCreateInfo ; fixing this makes subpassLoad() work. However this seems unreliable : I have an extra sampler in the pipeline_layout that I used to sample render target before having subpassLoad working but now if I remove it my device is "lost". It might be a geforce driver bug though.

Share this post


Link to post
Share on other sites
Laval B    12387

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Similar Content

    • By DavidTheFighter
      So I've been trying to implement a multi-threaded resource system w/ vulkan in my free time, where a thread can request a resource to be loaded, and it gets pushed into a queue. On another thread, the resource (as of right now, a mesh) gets loaded from a file, and I map the data to a staging buffer. The issue comes in where I record the command buffer to copy the data to a GPU buffer. I record a secondary command buffer w/ just the vkCmdCopyBuffer command, and push it to a queue to be executed from a primary command buffer on the main thread to a transfer-only queue. As far as I can tell, the staging works fine, and the mesh is drawn and looks perfectly fine, but my validation layers (VK_LAYER_LUNARG_standard_validation) spam tell me: "vkCmdBindIndexBuffer(): Cannot read invalid region of memory allocation 0x16 for bound Buffer object 0x15, please fill the memory before using," and the vertex buffer binding gives me an identical message. Both buffers were created with the proper bits, TRANSFER_SRC for the staging buffer, TRANSFER_DST for the gpu buffer (plus index and vertex buffer usage bits). I use Vulkan Memory Allocator from GPUOpen to handle buffer memory allocation, and I'm careful to make sure that the staging buffer is mapped properly and isn't deleted before the command finishes. The validation layers stop spamming telling me this error if I switch the copy commands to using primary buffers, even when recorded in the same way (i.e. just changing the level parameter), but everything I've seen recommends recording secondary command buffers simultaneously on worker threads, and submitting them on the main thread later. Any ideas on why my validation layers are freaking out, or did I just skip over something when reading the spec?
      Here's some relevant code:
       
    • By mark_braga
      If I have an array of storage buffers or constant buffers with descriptor type UNIFORM/STORAGE_BUFFER_DYNAMIC how would I specify the dynamic offsets in bind descriptor sets?
      Offsets:
      A[0] = 256
      A[1] = 1024
      A[2] = 4096
      A[3] = 8192
      Will the dynamic offsets array look like { 256, 1024, ... }? And what will be the dynamicOffsetCount? Will it be 1 or the array size?
    • By mark_braga
      Does anyone know what is Vulkan's version of the UAVBarrier in DX12?
      In my situation, I have two compute shaders. The first one clears the uav and second one writes to the uav.
      void ComputePass(Cmd* pCmd) { cmdDispatch(pCmd, pClearBufferPipeline); // Barrier to make sure clear buffer shader and fill buffer shader dont execute in parallel cmdUavBarrier(pCmd, pUavBuffer); cmdDispatch(pCmd, pFillBufferPipeline); } My best guess was the VkMemoryBarrier but I am not very familiar with vulkan barriers. So any info on this would really help.
      Thank you.
    • By nickyc95
      Hi,
      I posted on here a while back about rendering architecture and came away with some great information.
      I am planning on implementing a render queue which collects the visible objects in the scene and sorts them based on different criteria to minimise state change etc..
      The thing I am currently undecided about is: what is the best way to submit my draw calls?
      (I am wanting to support both OpenGL and Vulkan)
      At the moment I have two ideas for how I can handle it.
      The renderable handles the rendering (i.e. It calls renderContext->BindVertexBuffer(...) etc) and setup the renderer state Pro- Each renderable is full in control of how it renders Con - Have to manually manage state The renderable pushes RenderCommands (DrawMesh, DrawMeshIndexed etc) into a CommandBuffer that gets executed by the RenderBacked at the end of the frame Pro - Stateless Con - Seems more difficult to extend with new features Pro/Con - The front end only has a subset of rendering capabilities  
      There are more pros / cons for each, but I have listed a couple to help show my thinking..
       
      Any one have any comments on either of these two approaches or any other approaches that are typically used?
       
      Thanks
    • By mark_braga
      I have been reading about async compute in the new apis and it all sounds pretty interesting.
      Here is my basic understanding of the implementation of async compute in a simple application like computing the Mandelbrot fractal:
      In this case, the compute queue generates a texture of the fractal and the graphics queue presents it.
      Program structure:
      // Create 3 UAV textures for triple buffering // Create 3 fences for compute queue beginCmd(computeCmd); cmdDispatch(computeCmd); endCmd(computeCmd); queueSubmit(computeQueue, fence[frameIdx]); if (!getFenceReady(fence[frameIdx - 1]) waitForFences(fence[frameIdx - 1]); beginCmd(graphicsCmd); cmdDraw(uavTexture[frameIdx - 1]); endCmd(graphicsCmd); queueSubmit(graphicsQueue); I am not sure about one thing in this structure
      All the examples I have seen use vkWaitForFences but I thought fences are used for waiting from the CPU for the GPU to complete. Should I use semaphores instead, so the graphics queue waits on the GPU for the compute queue to finish if it's running faster than the compute queue? Any advice on this will really help to make efficient use of async compute.
  • Popular Now