|
in DX12 SetComputeRootUnorderedAccessView takes a gpu address, not a descriptor handle -- that means I can't use an append buffer on this slot, right? Because there's no way I can set it if it's a root UAV?
|
#
?
Nov 28, 2015 02:45
|
|
|
|
| # ? May 15, 2024 12:20 |
|
|
So we recently started our first 3D Programming course at uni. I chose OpenGL and have been learning with the help of LearnOpenGL which is fantastic. But my classmates who chose DX are struggling to find proper learning material online, which is odd since the teacher said the exact opposite was going to happen. The only LearnOpenGL counterpart that they can find is this site http://www.directxtutorial.com/ which costs $50 if you want access to the whole thing. So I was wondering if any of you DX people know of any good sites that teach you DX? (DX11 to be exact) I've been looking around too but I can't seem to find anything decent.
|
|
#
?
Dec 4, 2015 12:41
|
|
|
Microsoft has a bunch of samples and yes it's odd http://blogs.msdn.com/b/chuckw/archive/2013/09/20/directx-sdk-samples-catalog.aspx I'll teach you everything you need to know about dx11 for $49 :p
|
|
#
?
Dec 4, 2015 17:31
|
|
|
Torabi posted:So we recently started our first 3D Programming course at uni. I chose OpenGL and have been learning with the help of LearnOpenGL which is fantastic. But my classmates who chose DX are struggling to find proper learning material online, which is odd since the teacher said the exact opposite was going to happen. The only LearnOpenGL counterpart that they can find is this site http://www.directxtutorial.com/ which costs $50 if you want access to the whole thing. So I was wondering if any of you DX people know of any good sites that teach you DX? (DX11 to be exact) I've been looking around too but I can't seem to find anything decent.  you are taking a class where your prof just lets you choose whatever tools you want? How does that work at all?
|
|
#
?
Dec 5, 2015 21:05
|
|
|
lord funk posted:
We can choose between OpenGL and DirectX. On the OpenGL side we also pick what libraries we want to use. The lectures are all general 3D theory that applies to both APIs and we have three DX assistants and one OpenGL assistant that go through our assignments. So works well as far as I can tell.
|
|
#
?
Dec 5, 2015 21:37
|
|
|
What is "general 3D theory"?
|
|
#
?
Dec 5, 2015 22:14
|
|
|
Sex Bumbo posted:What is "general 3D theory"? We learn the APIs on our own. The general 3d theory stuff is basically just "Here's how to do X", like lighting and whatnot. Presenting the maths and formulas behind it and then we implement it ourselves.
|
|
#
?
Dec 5, 2015 23:08
|
|
|
I know you're not in charge of how the class is taught but isn't it weird that you're not getting taught how to use any APIs? Like do you learn how typical PC GPU 3D engines work?
|
|
#
?
Dec 6, 2015 00:23
|
|
|
Torabi posted:we have three DX assistants and one OpenGL assistant that go through our assignments Ah okay that explains a lot to me.
|
|
#
?
Dec 6, 2015 00:26
|
|
|
Sex Bumbo posted:I know you're not in charge of how the class is taught but isn't it weird that you're not getting taught how to use any APIs? Like do you learn how typical PC GPU 3D engines work? He has small examples in both APIs during lectures. But as time goes on it will be purely general theory. Like I said before, the DX people are struggling much more than me. I just read on LearnOpenGL and it's been going great. But yeah, I thought it was weird initially too that they didn't have more lectures on the APIs themselves. But seeing as how every day of the week there are four, sometimes eight hours where you can go and get help from one of the assistants, it gives you a lot of freedom and you can always get help. So it has been great so far.
|
|
#
?
Dec 6, 2015 01:16
|
|
|
I don't think he means in terms of "this is what API calls you make to do X" but in terms of "this is how a modern PC GPU works" and "these are the techniques modern 3D engines use"? b/c that's more important than how to do phong shading etc IMHO edit: of course, you have to get that stuff out of the way before you can get to subsurface scattering, SSAO, etc
|
|
#
?
Dec 6, 2015 05:58
|
|
|
The way I got into graphics was "here's the theory learn the api yourself" in probably a very similar manner, and in retrospect it was a pretty terrible way to teach for what I ended up doing. I don't really know how most lighting equations work. I don't think about them very much. I steal someone's shader and know enough about how lighting works to jiggle the code around until it works and looks nice in our own product (e.g. why is this equation dividing by 8PI? I know what it's for but why 8pi? Who cares). But I'm not really paid to copy paste google results from "good lighting shader", I'm paid to make it run fast, look good, and be usable by gameplay programmers. Those things are vaguely related to general 3D theory but like... not nearly as much as learning how to use the various APIs and GPUs. They're mostly all the same now too and going in similar directions, the days of really wacky graphics programming like the PS2 are kind of over. Metal and DX12 aren't too dissimilar. E: the fullscreen and miniengine samples at https://github.com/Microsoft/DirectX-Graphics-Samples crash if I close the program after switching to fullscreen mode, but I think this is probably a driver issue? It's an access violation when releasing a swap chain buffer. It doesn't crash if I don't release the buffers but then it complains about refcounts, naturally. Anyone else have this issue? Also if I use a swap chain of 2 or 4 buffers I get wild tearing, only 3 works properly. Really weird. Sex Bumbo fucked around with this message at 23:53 on Dec 6, 2015 |
|
#
?
Dec 6, 2015 23:29
|
|
|
Have some probably wrong observations about 3D Graphics APIs and Vulkan: http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan/
|
|
#
?
Dec 10, 2015 05:51
|
|
|
One little nitpick is that OpenGL was based on Iris GL, which wasn't some private internal API but rather was simply specific to SGI machines and their IRIX operating system.
|
|
#
?
Dec 10, 2015 07:58
|
|
|
Fast clear is a really weird thing to focus on, it's an optimization broadly useful to everything, doesn't require ugly hacks to implement, and still exist in Vulkan.
|
|
#
?
Dec 10, 2015 08:01
|
|
|
Doc Block posted:One little nitpick is that OpenGL was based on Iris GL, which wasn't some private internal API but rather was simply specific to SGI machines and their IRIX operating system. Thanks, reworded that a bit better. pseudorandom name posted:Fast clear is a really weird thing to focus on, it's an optimization broadly useful to everything, doesn't require ugly hacks to implement, and still exist in Vulkan. It was the easiest example of a "simple optimization" to explain the concept. Vulkan lets you choose between three load operations for attachments: VK_ATTACHMENT_LOAD_OP_LOAD, VK_ATTACHMENT_LOAD_OP_CLEAR, and VK_ATTACHMENT_LOAD_OP_DONT_CARE. Most applications should choose DONT_CARE, because it will work best for both tilers and classic hardware. The issue with glClear() is that it really sucks for tilers as part of the GL command stream. Tilers would much prefer to know in advance they don't need to copy the tile back in, and can work from a solid color fill. So it's really not the same as the glClear command, because it's explicitly done up-front.
|
|
#
?
Dec 10, 2015 08:18
|
|
|
On iOS, the call to glClear() is treated as a hint to the GPU that it doesn't need to copy the tile back in. I'd be kinda surprised if even Android didn't do the same. edit: Also, in the third paragraph you state, "OpenGL has the advantage of being implemented independently by most vendors, and is generally platform-specific." Should that be "is generally not platform-specific" ?
|
|
#
?
Dec 10, 2015 08:34
|
|
|
It's a tad more complex than that. You need to pay attention to the different buffers. Android leaves this up to the device, because some devices don't have tilers. I know of a bug caused by this optimization in our Mali drivers when a game did the equivalent of: glClear(COLOR | DEPTH); drawMesh(skybox); glClear(COLOR); drawMesh(player); There's reasons why it didn't just turn color writing off in the first place, too, but I forget the details -- I think they used glReadPixels on the color buffer to do coarse picking of some sort. It was mostly an easy fix (they already tracked most of this, but didn't handle two clears in one frame), but still took a day or two to track down. Again, by being part of the command stream, it's more complex, since the clear doesn't necessarily happen at the start of the frame. edit: and fixed the wording issue again, gah. Thanks. I did say it was half-finished.
|
|
#
?
Dec 10, 2015 08:52
|
|
|
IIRC, Apple's OpenGL docs for iOS specifically say that you should always call glClear() at the start of a frame because it's a hint to their OpenGL driver that the application doesn't care about the previous frame's contents and so the GPU can just clear the tile cache instead of loading the previous frame into it. edit: that's for iOS/tvOS, not OS X, obviously. edit 2: which isn't as fast as being able to tell the GPU not to bother loading the previous frame AND not to bother clearing it, but is better than having the GPU fill the tile cache with the previous frame's contents every frame, though. Doc Block fucked around with this message at 09:13 on Dec 10, 2015 |
|
#
?
Dec 10, 2015 09:07
|
|
|
Suspicious Dish posted:Have some probably wrong observations about 3D Graphics APIs and Vulkan: http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan/ I really like little "inside baseball" industry tidbits like the Nvidia stuff.
|
|
#
?
Dec 10, 2015 18:13
|
|
|
quote:An ImgTec engineer mentioned that dev-to-triangle time on Vulkan was likely two weeks to a month It admittedly took me an embarrassing amount of time to get dx12 to clear the screen but after that everything accelerates quickly.
|
|
#
?
Dec 10, 2015 18:50
|
|
|
I think the trick is that the dev-to-efficient-game-engine time ends up being much shorter in turn.
|
|
#
?
Dec 10, 2015 20:38
|
|
|
Ralith posted:I think the trick is that the dev-to-efficient-game-engine time ends up being much shorter in turn. Yeah. The "Hello 3D World" program is going to be a lot bigger/more complicated in both DX12 and Vulkan (moreso relatively in Vulkan due to ability to write super basic programs in GL) but a lot of that is due to requiring a lot of boilerplate code that any "real" application is going to need anyways.
|
|
#
?
Dec 11, 2015 17:35
|
|
|
Licensed engines are also a lot more common now, so Unity or Epic can incur that time and then everyone else gets to skip it.
|
|
#
?
Dec 11, 2015 17:40
|
|
|
haveblue posted:Licensed engines are also a lot more common now, so Unity or Epic can incur that time and then everyone else gets to skip it. Yes, and this is really part of the plan. If you look at the entire rendering stack, from user API down to GPU silicon, as a finite amount of work distributed among all the companies working in the industry (from Indie Dev to Epic to Microsoft to NVIDIA) then you are really redistributing a lot of the optimization work done at the driver/OS level and pushing it into user space. There may be efficiencies that can be gained by that, but ultimately there is still unavoidable added work that's either going to have to be done by developers who are currently focusing on other existing tasks, or by new/expanded middleware. Part of the reason why companies like Epic are pushing the new APIs is that it simultaneously give them the ability to deliver more performance and creates an even bigger niche for them to fill.
|
|
#
?
Dec 11, 2015 18:40
|
|
|
And yet still a lot of companies with engines built in the last year are also able to handle the task. Part of it is because Vulkan's design really doesn't give you a big opportunity to "get it wrong" like you do with high-level APIs, and there's a lack of strange or opaque behavior. Experienced engine programmers aren't upset at Vulkan for making them do more work, they're thankful they don't have to guess what the driver is doing anymore.
|
|
#
?
Dec 11, 2015 18:43
|
|
|
Suspicious Dish posted:And yet still a lot of companies with engines built in the last year are also able to handle the task. Oh, sure. And, even if the API change doesn't provide any new efficiencies over the old stack, the fact that the code is being done at the middleware level instead of the OS/Driver level means developers can have multiple potential solutions to choose from instead of just trying to hope that the end user's platform developers got it right. The corollary to this is just that you're going to have a lot more modules of code implementing the same thing at a much lower level than before, as opposed to a single code base (kernel module/driver) that is getting way more testing because it's being used by everything. Also, "Guessing what the driver is doing" is a double-edged sword, because sometimes the driver does things in an unspecified manner because what the best practice would be might change between hardware generations. I think there's going to be somewhat painful transition with a perf issues and stability bugs, but hopefully expertise and middleware will get to the point where that's no longer as much of an issue and we can reap the overhead reduction benefits.
|
|
#
?
Dec 11, 2015 19:08
|
|
|
Yeah, I'm hoping there will be some nice Vulkan libraries. The benefit will be that all the complexity will be in the libraries, where it can be inspected and debugged, and not in the drivers that are black boxes of crazy. And of course the APIs for those libraries can be a lot saner than the OpenGL API.
|
|
#
?
Dec 12, 2015 00:03
|
|
|
A small side benefit of Vulkan/Metal/DX12 being new, modern APIs is that all the information you find online about them is also new and modern. Right now, if you Google for "how to do X in OpenGL", half the links are to articles covering OpenGL 1.x or 2.x.
|
|
#
?
Dec 12, 2015 01:49
|
|
|
I feel like an idiot for asking, but how do you set individual modelViewMatrix matrixes for different models on screen in Metal? In OpenGL I would just set the uniform's modelViewMatrix before each draw call, but Metal is only using the last one I set. I'm pretty sure this is by design, but I'm just blanking in how to do this. edit: oh I think I have to make my uniforms buffer an array and fill it with the individual model matrixes edit 2: no, I take it back. I have no idea how to do this. lord funk fucked around with this message at 17:48 on Dec 12, 2015 |
|
#
?
Dec 12, 2015 16:36
|
|
|
Keep in mind that Metal doesn't draw anything when you encode a draw call. So if you make a single, universal uniform buffer for modelViewProjectionMatrix and friends and then keep changing the contents before committing the command buffer, only the last contents will be in there when it actually does the draw calls. edit: there's a method you can call that basically does what OpenGL does (copy the uniforms into driver-managed memory) without the overhead of creating a new buffer, with the caveat that your uniform struct has to be at least 256 bytes and a multiple of 16 or 256 bytes long (depending on if you're writing for iOS or OS X). I'll look it up when I get home in a few hours. Doc Block fucked around with this message at 18:04 on Dec 12, 2015 |
|
#
?
Dec 12, 2015 17:59
|
|
|
Doc Block posted:Keep in mind that Metal doesn't draw anything when you encode a draw call. So if you make a single, universal uniform buffer for modelViewProjectionMatrix and friends and then keep changing the contents before committing the command buffer, only the last contents will be in there when it actually does the draw calls. Figured that part out. So I have to create a MTLBuffer of size models.count* sizeof(uniforms), and then somehow pass a model index to look up the correct uniforms? Is that about right?
|
|
#
?
Dec 12, 2015 18:01
|
|
|
If that's what you want to do, yeah. My engine cheats and just gives each object its own uniforms buffer. So it attaches their buffer before issuing the draw call for them, and since each -setVertexBuffer... call is an individual command it's OK. Most objects don't change often in my game, so their uniforms don't change often and so it was easier to just have the objects cache them in a Metal buffer and set that buffer at draw time. Please don't laugh at me...
|
|
#
?
Dec 12, 2015 18:12
|
|
|
Doc Block posted:If that's what you want to do, yeah. No, your way is exactly what I needed. 
|
|
#
?
Dec 12, 2015 18:22
|
|
|
https://www.khronos.org/vulkan "bad news it's delayed, but the good news is, it's coming soon!" Guys that's just bad news. That's now how good news works. I'm vaguely anxious about adding support to my DX12 stuff in the way one is anxious about going to the dentist. Sex Bumbo fucked around with this message at 00:13 on Dec 19, 2015 |
|
#
?
Dec 19, 2015 00:10
|
|
|
I've been told by several companies that they're done with all of their Vulkan work and are waiting on the green-light from Khronos. The conformance suite hit a few last-minute snags with licensing and legal issues -- some images that were donated from an internal test suite weren't properly licensed, so they're cleaning that up.
|
|
#
?
Dec 19, 2015 00:21
|
|
|
I hope it doesn't become this thing that's just for big name companies with tons of cash like epic and ignorant of every small hobbyist or developer.
Sex Bumbo fucked around with this message at 00:48 on Dec 19, 2015 |
|
#
?
Dec 19, 2015 00:43
|
|
|
Vulkan? No, it will be freely available and open upon release. That's why every part of it has to go through arduous legal review processes, because if you accidentally sneak in a texture from a copyrighted game, well, you can't release that publicly. Drivers, reference documentation, samples, SDKs, tooling, conformance test suites, benchmarks and more will all be available when it is released.
|
|
#
?
Dec 19, 2015 01:24
|
|
|
Yeah I'm just salty about how long it's probably going to take to come out.
|
|
#
?
Dec 19, 2015 01:59
|
|
|
|
| # ? May 15, 2024 12:20 |
|
|
If anything, Vulkan represents a drastic increase in accessibility--no longer will we be so dependent upon proprietary "this is how to make the driver happy" incantations.
|
|
#
?
Dec 19, 2015 02:04
|
|