Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1415 Excellent

About Funkymunky

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Funkymunky

    Vertex Shader to Multiple Pixel Shaders

    Cool. So just to be clear, on a technical level, the options are either stream-output or compute shader transformation to a buffer that I then bind to a pass-through vertex shader?
  2. I'm doing some mesh skinning in my vertex shader, and I have a depth pre-pass in place. I'm not crazy about doing all the vertex transformation twice for the skinning; is there a way to have one vertex shader be the input to multiple pixel shaders? Or do I have to do a vertex shader stream-output, and then set that as the input for the pixel shader somehow?
  3. Funkymunky

    OMSetRenderTargets per Command List?

    I guess that's as clear cut as it gets.  Thanks!
  4. Funkymunky

    OMSetRenderTargets per Command List?

    Is it a necessity per list though?  Wouldn't putting in a fence to ensure the correct setup has been processed be less work for the GPU than calling OMSetRenderTargets, RSSetViewports, and RSSetScissorRects for every list?  To clarify, I'm making those calls per list now, but I'm just wondering if there's a better way to do it...
  5. Let's say I have three command lists, A B and C.  They are guaranteed to be submitted in order.  If I call OMSetRenderTargets on list A, can I then ignore calling it on the B and C lists and assume they will be writing to the same render target?
  6. Funkymunky

    Visual Studio C++ "if constexpr"

    That's the conclusion I'm coming to as well, and upon further review you are correct about using /std:c++latest. Ah well, thanks for the help!
  7. Funkymunky

    Visual Studio C++ "if constexpr"

    I had found that and tried it, but I figured it was just deciding which version of the standard library to include.  It doesn't make a difference for this, I still get a compiler error like it can't understand "if constexpr".
  8. I just upgraded to Visual Studio 2017, because I wanted to use "if constexpr" in my code.  It seems like it's not supported: If I just do something like "if constexpr(true)", I get an error of "expected a '('"   Does anyone have experience with this?  Is there some setting I need to flip to get C++17 compilation enabled?  I didn't see anything in the project settings...
  9. Funkymunky

    Ok... The True Final Word on Rube...

      No my friend, that's not how this works.  Nobody has to execute your vision for you.  You won't even fully detail what it is; you just keep reiterating how much experience you have, as if that means we'll accept you as the authority on game design.  If your idea doesn't see the light of day, then it's entirely YOUR fault for not being able to work with people.   Also, stop calling us arrogant when you make statements like that.  That is like the epitome of arrogance.
  10. Funkymunky

    A Final Word About Rube

    Hey man, I was just trying to give you some friendly advice.  I've watched you consistently get this type of reaction.  The reason for it is that you come off as extremely disrespectful.  I'm sure you have your reasons, your frustrations about not being understood or taken seriously for the magnitude of your game idea.  Or the fact that you feel like your experience in game design makes you an authority.  That you clearly feel like you know better than the people on this site.  But just... as a word to the wise... it's not working.  Again, this is why you have "30 years of banging my head against a brick wall."  You're being rude, disrespectful, and you're belittling the people that you are apparently reaching out to.  It's one thing to be confident in one's ability and knowledge; it's quite another to tell people that their experience is less valuable and that they should just shut up and listen to you.
  11. Funkymunky

    A Final Word About Rube

    Wow, this is nuts.  So you're angry that no-one is jumping on board to help you create your vision of "Rube"... even though you won't really describe it in detail.  The best you'll offer is that it's a "functioning simulation of God"... and yet your issue is that everyone else is arrogant.  Even though you've responded with statements like: "An attempt by the adults to explain the current height of the field of game and simulation design to the spoiled little children playing in the sandbox at the edge of our field" and "You could learn a lot if you put down your bucket and shovel and listened to your betters" Pirate Lord man... I remember your first epic meltdown.  You haven't learned yet that you need to do a better job interacting with people?  "30 years of banging my head against a brick wall" and you haven't stopped to think that maybe it's how you approach people?  It's great that you're enamored with your idea, it really is.  Passion is a valuable thing in life.  But if you turn people off by being rude to them, or getting exasperated that they won't just blindly trust your vision... then they aren't going to help you...
  12. Funkymunky

    [D3D12] Descriptor Heap Strategies

    After some deliberation, I think I'm going to adopt the following scheme:   I'll create one or more "offline" heaps to create descriptors in, as this will let me create resources in separate threads.  For the "online" heap, I'll use a freelist allocator to give me descriptor ranges.  I'll track three lists for maintaining this.  The first will be a list of available allocations, sorted by size (a normal freelist).  The second will be a list of allocated and deallocated ranges, sorted by their offset from the start of the heap.  The third will be a list of just the deallocated ranges, also sorted by their offset from the start of the heap.  (The second and third lists will use the same structures, with each structure having pointers to its neighbors).   Every frame I will run a basic defragmentation pass.  It will look at the first entry in that third list (deallocations).  If the neighbor to the right of that entry is also a deallocation, then I will coalesce the two into a single deallocation.  If the neighbor is instead already-allocated, then I will shuffle that allocated range to the left, essentially bubbling the deallocation toward the end of the heap.   In practice, I'll probably split the "online" heap into multiple regions (one for each frame).  This way I can shuffle descriptors after a fence without disrupting something that's being used.  I think as long as I don't hammer the heap with constant allocations and fragmenting deallocations, this should keep me relatively well managed.  And even if I do, I can always increase the number of defragmentation passes to keep things in check.
  13. Funkymunky

    [D3D12] Descriptor Heap Strategies

    Until now I've just been creating two descriptors for any per-frame resources (mostly buffers that are constantly updated),  But I've also been calling SetGraphicsRootDescriptorTable for every bound resource, rather than batching things into contiguous regions and minimizing those calls.  This has worked fine for the relatively small shaders I've tested my scenes with, but it's clear now that this strategy could quickly hit a wall.   It's pretty much a classic allocation problem, except there's no reason not to apply extra memory/processing power to making the allocations/deallocations as fast as possible.  I am trying to dream up a faster scheme, but so far it seems like the ring buffer / stack allocator strategy is the way to go.   That bindless strategy is intriguing.  That approach would use a common root signature with access to every descriptor, right?  It might be tricky getting root constants to work with that, but the tradeoff for not having to manage the descriptor heap is enticing...
  14. Funkymunky

    [D3D12] Descriptor Heap Strategies

    I feel like a lightbulb has just turned on over my head.  That makes a lot more sense.  Thanks for the insights!
  15. Funkymunky

    [D3D12] Descriptor Heap Strategies

    I guess what I don't understand is why there would be a lot of objects with transient lifetimes.  It seems like most textures and constant buffers are going to stick around for awhile.  In fact it seems like adding new descriptors/removing old ones would happen pretty infrequently.  Can you describe a use case where a majority of objects would require new descriptors every frame?  And also, are you saying to call CreateShaderResourceView/CreateConstantBufferView every frame?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!