next »

[Crimsontide]

IMO its better than all the other graphics APIs... that still doesn't mean it isn't without its issues.

Basically its all the fun of Direct3D 12, in an OS-independent format, without all the mess of OpenGL (because lets be honest, OpenGL has got to be one of the worst designed things I have ever seen).

There's a lot of initial boilerplate code, but you get control over everything so its stupid efficient.  Also it can work with pretty much any programming language.

Here's a really good tutorial on how to get started: https://vulkan-tutorial.com/Introduction

[oahda]

And if you don't feel like tackling it in all its complexity there's now this (haven't looked into it, can't speak for or against it, just letting you know): https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ

[Crimsontide]

On to my rant...

So I get the reason we have VkQueue's.  Much like VkCommandPool, we can render across multiple threads without complex synchronization.  Make a VkQueue for each separate thread, and voila, multithreading rendering!!

Except VkQueue's are fixed for a given device, which means sometimes I have a ton of queue's (like on NVidia devices) and others give me 1 queue (like on Intel devices).  So what was the point!!!?  Why even have them if we can't use them??

[qMopey]

All these fancy gfx APIs, and here I am using DX9 

Not ganna change what isn’t broken!

[JWki]

On to my rant...

So I get the reason we have VkQueue's.  Much like VkCommandPool, we can render across multiple threads without complex synchronization.  Make a VkQueue for each separate thread, and voila, multithreading rendering!!

Except VkQueue's are fixed for a given device, which means sometimes I have a ton of queue's (like on NVidia devices) and others give me 1 queue (like on Intel devices).  So what was the point!!!?  Why even have them if we can't use them??

You... Can use them? On devices that support it. If the target hw doesn't support it of course you can't use it but you can still use it on other hw that supports it. Write once ship everywhere is a lie, every serious graphics app (and if you use Vulkan it better be because you are working on a serious graphics app) will have several hw specific code paths.

Also the big threading benefit with Vulkan is that you can do parallel command generation, not so much the actual submission queue, which allows you to do your app side rendering in parallel.

[Crimsontide]

With Semaphores/Pipeline Barriers, all dependencies are already described succinctly.  If parallel rendering was all the was needed VkQueue's don't need to exist/are completely redundant.  One big queue for each queue family that everything is thrown at would be sufficient.  The only thing that VkQueue's bring to the table is multi-threaded rendering without complex synchronization, and yet, because I can't count on them existing I'm going to need complex synchronization for multithreaded rendering to compensate.  It makes no sense...

90% of Vulkan makes perfect sense, but there's that 10% that just baffles me.  I completely understand RenderPass's and the need for them, pipelines are great, manual memory binding, command buffers, synchronization primitives (for the most part), etc...  As the programmer/designer I know exactly what effects I need and when I'll need them, so creating pipelines or render passes, or allocating/binding memory all makes sense that I would have direct control.  I have the information to make that decision, hence I should be the one that makes it.

And then we get to queues/submission/presentation and they completely dropped the ball.  I don't have the information needed to properly schedule submissions on a video card.  Every card/drive combo does it differently, there's temperature concerns, fan speeds, interaction with OS scheduler, hardware cache's, a thousand little things that all make a huge difference.  That's something that drivers/API should handle.

Exposing 'hardware' queue's was a HUGE mistake IMO.  When we program for CPUs, we don't manually schedule threads for execution, you throw threads/tasks at the OS and let it handle that because it knows what needs to be done...

The whole excuse that Vulkan is 'close to the metal' and 'you should need multiple rendering paths' is silly.  Both are ignoring the bigger picture.  The reason why Vulkan/DX12 are superior was that in previous APIs the drivers lacked sufficient information and were forced to guess.  Setting up all the constructs that a game/app needs on-the-fly meant complex heuristic analysis, weird caches, multithreaded JIT compiling, complex memory management schemes, multiple paths for different games, and all sorts of hacks to get good performance; simply because they didn't have the information.  So handing that off to the developer made perfect sense, I don't need any of those since I know what I'll need and what to use.

But now we have the same problem in reverse with queue's.  I have to write weird/complex systems with caches and multiple paths to get good performance??  If it was considered an intractable problem for driver writers, its certainly an intractable problem for developers.

Vulkan is actually not difficult (I find it easier than OpenGL), except for that last 10% which they completely fucked up with...

I don't get it, how can people make something so good, and then completely drop the ball on something this simple?

[gimymblert]

I can't believe simple math is getting the better of me, I'm still struggling with the relief function shader, now I'm trying to generalize to any curve, by picking the 2d part and swiping it along one axis. Which mean computing an intersection in xz, then with the height find the intersection in z using the slopes. But a simpel line segment intersection refue to cooperate, i mean it's like math for preteen ... 

[Crimsontide]

Ughgh... sometimes I hate forums.

Just answer the fucking question and stop trying to weasel out of it by telling me that's not how its done.  Or just don't answer, but I shouldn't need a 10 page mathematical proof to simply get an answer.

[ProgramGamer]

I’m guessing you’re talking about another forum, or is this still about vulkan queues?

Anyway, yes, it’s a bit frustrating when you want to know something and people start questioning your motives. However, I would at least give them the benefit of the doubt. They may be right on some level so it may be in your interest to consider their alternate approach. Also, as frustrating as it is, it may also be that you didn’t explain yourself with enough detail for people to understand why you went with the aproach you did. Asking questions online can be a game of patience, but I find that it’s worth it to remain patient through it.

Plus, in the case where they’re actually wrong, you still have this thread to vent to :p

[Crimsontide]

Its not this forum.  This one is one of the good ones, that's why I can vent here

[Ordnas]

It is something that I noticed also on forums (TIG and others), more towards programmers to be precise, but it is a behaviour that I encounter at work also from some people, so I am used to and I expect that behaviour more or later. I just be polite and that's all.

[gimymblert]

Asking math advice on gamedev forum don't yield good result, and actual math forum are so mathy jargony notationy they are unbearable

[Crimsontide]

Asking math advice on gamedev forum don't yield good result, and actual math forum are so mathy jargony notationy they are unbearable

Are you still working on that relief shader?

[gimymblert]

yes, I'm (trying) generalizing to swiping (roughly convex) curve and wrapping parralax primitive, but my quote is more general than that, I'm also on other gamedev forums, and generally math question post get pretty windy quickly, unless it's the usual suspect.

[Crimsontide]

Ya, math papers and forums are just awful, and I have a minor in mathematics.

They never define their variables, and constantly use ambiguous terms.  But of course ask them to define their variables/terms and they insist there's only '1 correct definition', theirs, and that everyone else is wrong and should know exactly what they are talking about.

I feel your pain!!

[BorisTheBrave]

Programmer and mathematician here. The disciplines have a very different approach to explaining stuff. Programmers are taught to explain things in extremely verbose, precise ways, because that is all computers understand. Mathematicians explain to other mathematicians, so they can do "higher level code" that programmers can only dream of. And it's necessary to get anything done - have a look at formal theorem proving as a counterexample.

If you are going to go onto a maths forum, they will expect you to do a decent amount of work for yourself. And it's not mechanical work, it's "understanding". It's just not in the maths ethos to give a copy paste snippets as that is not the point as far as they are concerned.

If you want the best out of a mathmo response, you are going to have to be upfront with what level of knowledge you have going in - they will rephrase answers based on that, within a range. And define your own terms, then you don't need worry about confusion there.

Finally, be prepared to learn a new subject. If someone asks a questions best answered with vector math (very common in game forums), there's no point giving an answer that skirts around vector maths - the asker will just be back 3 seconds later with another question. You'll get an answer in vector notation, and complaints that you don't know vector maths will be denied. I'm sure you ladies and gents already appreciate why vector maths is relevant to games - now try to imagine the same thing coming up for something outside your understanding.

Edit: Papers though, you're just screwed.

Edit 2: Also, forums like these cannot format latex equations, and one cannot assume users will understand raw latex. That means that a great deal of expressive range lost - one ends up making up a lot of terminology, because the standard maths terminology only works on paper or latex. Imagine if I told you to demonstrate code without using any symbol characters!

[qMopey]

So what I'm hearing from you is that in general math guys like to assume superiority and teach others irrelevant information in favor of answering the question at hand.
 

[J-Snake]

Programmers are taught to explain things in extremely verbose, precise ways, because that is all computers understand. Mathematicians explain to other mathematicians, so they can do "higher level code" that programmers can only dream of.

"Programmer" is a broad term nowadays, as well as "mathematician". There are varying levels of competence on both sides. In general, both have to be able to operate on multiple levels of abstraction and use logic to derive conclusions.

btw. one of the worst written papers I read so far, Adaptive LL Parsing:
http://www.antlr.org/papers/allstar-techreport.pdf

[gimymblert]

I complaining because I'm in a weird limbo that is at the cross section.

For example, I currently trying to make raycasting in wrapping (modulo) space in single hit, so the answer is that there is no mathematical inverse to the modulo function. So this is what I'm being told.

But here is the thing, I don't need it, using the slopes I can infer the delta of space across the bound, and ten it became just a division of the empty space size with the size of the slope delta per cell. Using a axis aligned square primitive inside the cell I can get the hit by comparing the size of the primitive and the size of the cell to infer the empty space. I demonstrate that in my use case I can effectively raycast analytically in modulo space.

But that's the demonstration for a square inside the cell. I want to intersect a circle, so I need a new approach. Using the slope delta trick, instead of crossing empty space I try to use the angle from the entry at the boundary toward the center of the circle, which I dot with the tangent angle to the entry point (basically computing the visibility cone). Once the ray is inside the visibility cone I got a hit.

Now the problem I have, is that I don't know how to compute the formula that give me the delta of the angle for the delta of the slope, and how to compute the delta of the tangent, and find the intersection between the two (when the ray will be inside visibility). I think I basically need derivative to reason on, my math knowledge breaks down here, I have the tangent formula, but I don't know how to derive the angle to circle formula (doesn't have to be angle, it's the variation of the vector). Also some stuff are in parametric and some stuff are in f(x) = ax+b like of function (I'm not sure what is the term), I don't know how to bridge the gap between these equation. That's as far as I can get.

I have the intuition it's too simple for mathematician to bother and too complex for programmer to care. I have zero answer, not even to tell me if it's possible or not.

[Crimsontide]

Mathematicians explain to other mathematicians, so they can do "higher level code" that programmers can only dream of. And it's necessary to get anything done - have a look at formal theorem proving as a counterexample.

Completely disagree.  Both mathematics and programming are just problem solving in the end.  Whether it be a proof or an algorithm, its essentially the same thing. 

The thing is mathematicians for some reason think they are smarter than others, and you get the quintessential 'smart idiot'.  They think that because its hard for them, then they must make it hard for others, and hence get all wrapped up over making things look as complicated as possible.  They think that math is obscure symbols and arcane runes jotted haphazardly over reams of paper.

Poorly written math is like poorly written code, indecipherable to nearly anyone but the author.  The difference is in the programming world where people are forced to work in teams, that sort of sloppy notation is discouraged.  In math its not only tolerated but seemingly encouraged.  If mathematicians were held to the same standard as programmers, math papers would be a whole lot nicer/cleaner.