nicebyte

2015 called

No, that is exactly the reason I am bringing up physics. There used to be a time when a singular person could make an outsized impact. In the recent past though, this has not been the case: significant breakthroughs are usually the result of coordinated effort of many individuals. Is that really a valid reason to not do physics?

now, if you said "don't get into it because your primary employment prospects would be games or film industry, which are known to be less than stellar towards their workers" - that would be a different story.

My only additions to the article would be to study your probability/statistics (can't do efficient path tracing without it) and get comfortable with integrals, especially integrals on a sphere (physically based rendering will be a lot easier to understand).

Ridiculous justification.

"Where is todays Jon Carmack?"

Where is the "John Carmack" of ML? Where is the John Carmack of physics? This hero worship crap needs to be left in the past. There isn't a singular active researcher you can point to and say "this person has made the field what it is today". There are very influential papers, but they all have multiple contributors. Is that really a valid reason to not engage in a particular area of research or engineering?

And who cares anyway? No matter what you choose to do with your time, chances are that you will not have that much of an impact on your chosen discipline. You should choose how to spend your time based on whether an activity genuinely interests you, not on whether you think it would be easy to get recognition.

"Github Repo" "Find Us on GitHub"

????

general rule of thumb is that you never want gamma-corrected values if you intend to be doing any sort of math with them. the only exception is when you want to match the behavior of softwares that actually do all the math with pixel values in sRGB space (I think that's what photoshop does but don't quote me on that).

there isn't much that is "arcane" about gamma correction itself (as in, the math itself is really simple).

at the fundamental level, if a surface is illuminated with one lightbulb and we add another light bulb, the difference is exteremely noticeable to the human eye. if we add one more lightbulb to a surface that is already illuminated by a hundred light bulbs, there will be no perceptible difference. the exact response can be modeled with a pretty simple power law (with a modification in the low range, as the article mentions).

that's all there really is to "gamma correction". it's a hack that exploits this quirk of the human visual system in order to more efficiently allocate bits for encoding different "lightness" values.

all of the confusion and bugs stem from one or more of the systems in the chain that forms the final image, making an incorrect assumption about what the others are doing. it's a bit like coordinate spaces in that regard.

that just sounds like DNS but more centralized and not super human-friendly...

but dynamic DNS is a thing. I've had setups for it since god knows how long, though admittedly not on my phone.

I am confused why this is needed.

IP addresses can break, without warning, and it's outside of your device's control.

We have DNS?

Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not.

So are domain names? This page does not do a good job of helping me find what it is that I'm missing.

If done right, this is more like a monthly bus pass

when you re-crop a photo or use the perspective tool, you are literally distorting the image. not to mention, all of the processing that happens in modern cameras before you even see the image. in the case of a modern smartphone in particular, I think it's fair to say that you never really see the "real" image as captured by the CCD sensor, and even if you did you would not like it anyway.

they're technically not wrong. C is literally an "abstraction" of the machine. As we know, the whole point of an abstraction is to ignore the multitude of details :-)

250k for base pay is about in line with median I'd say.

If 250k was the total comp (taking into account bonus/stocks/what have you) then yeah, you definitely should have negotiated.

"outgroup"? what outgroup? we're talking about inanimate objects here. by your own logic, you treat your home appliances as an outgroup so you must be secretly a dangerous psychopath. or do you thank your microwave after heating leftovers?

it's a neat experiment but I think it's ultimately flawed because color is usually perceived in context, and depending on context I could easily see anyone reinterpreting the hues they labeled "green" in this test as blue, and vice versa.

EDIT: in general, blue is a pretty fascinating color. yes, many cultures have a somewhat blurry distinction between blue and green. Some others seem to differentiate shades of blue that others don't (i.e. in Russian "голубой" and "синий" refer to distinct colors but in English those would be just shades of blue). I guess there's something about photons in that energy band that messes with perception. https://en.wikipedia.org/wiki/Non-photo_blue

There is no consequence for choosing blue

there are consequences in both cases.

I've found Trellis specifically to be very "over-promise and under-deliver".

Nothing i tried with it got even close to th level of quality that they were advertising - felt like a bunch of examples were hand-picked, at best.

jumps is another one. jmp can have many encodings depending on where the target offset you're jumping to is. but often times, the offset is not yet known when you first encounter the jump insn and have to assemble it.

I want a single-line malloc with zero care about usage flags and which only produces one single pointer value

That's not realistic on non-UMA systems. I doubt you want to go over PCIe every time you sample a texture, so the allocator has to know what you're allocating memory _for_. Even with CUDA you have to do that.

And even with unified memory, only the implementation knows exactly how much space is needed for a texture with a given format and configuration (e.g. due to different alignment requirements and such). "just" malloc-ing gpu memory sounds nice and would be nice, but given many vendors and many devices the complexity becomes irreducible. If your only use case is compute on nvidia chips, you shouldn't be using vulkan in the first place.

Not sure if this is an "oh, no" event.

it's not.

descriptor sets are realistically never getting deprecated. old code doesn't have to be rewritten if it works. there's no point.

if you're doing bindless (which you most certainly arent if you're still stuck with descriptor sets) this offers a better way of handling that.

if you care to upgrade your descriptor set based path to use heaps, this extension offers a very nice pathway to doing so _without having to even recompile shaders_.

for new/future code, this is a solid improvement.

if you're happy where you are with your renderer, there isn't a need to do anything.

just use the vma library. the low level memory allocation interface is for those who care to have precise control over allocations. vma has shipped in production software and is a safe choice for those who want to "just allocate memory".

some of this is what's khronos standards are theoretically supposed to achieve.

surprise, it's very difficult to do across many hw vendors and classes of devices. it's not a coincidence that metal is much easier to program for.

maybe consider joining khronos since you apparently know exactly how to achieve this very simple goal...

assembler is far from trivial at least for x86 where there are many possible encodings for a given instruction. emitting the most optimal encoding that does the correct thing depends on surrounding context, and you'd have to do multiple passes over the input.

shameless plug: if you want to understand the content of this post better, first read the first half of my article on jumps [1] (up to syscall). goes into detail about relocations and position-independent code.

[1] https://gpfault.net/posts/asm-tut-4.html

including ai generated illustrations in your articles or presentations is very cringe

my comment isn't about things being written using c/make/whatever, it's precisely about the faulty assumption that complexity is needless.

yeah no. I've mainlined dwm + dmenu all the way back in 200x, I've written tons of makefiles and have the scars to prove it.

These days I'm off of this minimalism crap. it looks good on paper, but never survives collision with reality [1] (funny that this post is on hn front-page today as well!).

[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...

I bet 90% of the reason this is on the front page is the Berkeley mono font. the system itself sucks.