While in general I am very much in favour of playing both sides of an abstraction, I would argue that RTL is nowhere near the top of the stack.
In the GPU world, you have games, which are built on game engines, which are built against an API, which is implemented in a driver (which contains a compiler!), which communicates through OS abstractions with hardware, which is written in a HDL (this is where you write RTL!), which is then laid out in silicon.
Now each of these parts of the stack have ridiculous complexity in them, and there are definitely things in the upper layers of the stack that impact how you want to write your RTL (and vice versa). So if your stack knowledge stops at RTL(which, honestly there is absolutely nothing wrong with!), there is still lots of fun complexity left in the stack.
Modern gpus + drover stack usually had more than one frame in flight. You have to output a frame every 4ms, but you do not need the latency from the start of the application rendering code to the frame being on screen to be 4ms - pipelining is allowed. But keeping that pipelining down to a minimum is also important, as it contributes to input lag which gamers care about.
On reading your original post again, what you experienced (both being super exhausted after work, and a shower helping) resonates with my what I felt early on in my career.
Things that helped were
- Take care of primary needs during the workday. Eat, drink, bathroom breaks. The basics. I could get so caught up I would forget about those things.
- More experience helps. Work is still incredibly taxing mentally, but as I've grown a bit more battle worn I don't have to second guess whether my work is good enough all the time, which is also exhausting. Being introverted, having been in the same place for a while (not to mention - being remote) also helps, I'm not being bombarded with people I don't know any more since I know them all.
- Having kids was brutal in terms of taking time and energy, but luckily it somehow came with an 'extra gear' to cope with it. Totally worth it though, I can only hope it becomes an option for you with time
- I also found that having a plan for what to eat after work was worthwhile, so I didn't have to think - just cook it and eat it.
- If something work relates is spinning in your head, write yourself an email about it and postpone it until tomorrow.
Not sure if any of this is helpful to you, but worth a shot :)
That's it, really, and I love it. Nothing makes me snap out of it like being assigned a role from Paw Patrol by my two year old, and going off on some rescue mission. It's pure bliss.
I totally agree that the existence of these drugs make the world a better place. I also totally agree that there should be significant financial upside to developing drugs like these, after all we do want to incentivise making the world a better place.
But surely there must be a middle ground? This seems to be priced by a "what are people willing to pay for this?"(a lot, given its life saving/changing nature) vs "what do we need to charge for this, including a healthy profit for everyone involved". (much less, presumably?)
I fundamentally dislike, from the perspective of the patient, the thought that precisely /because/ the drug is desperately needed by someone through no fault of their own, it /deserves/ to be expensive.
The foundation getting a cut of the success and reinvesting in new opportunities sounds good though, thanks for pointing that out!
That particular drug was on the news in Norway this week because it is so incredibly expensive that the state don't want to pay for it. We are talking 20-30k USD per month per patient.
I partially excused that mentally with a "but yeah, research is expensive", but now learning that it was paid for by donations ruins that argument.
The fact that the state don't want to pay for it is of course also debatable..
I don't think they can use jpg directly, that would be a waste of transistors given that the graphics world use other compression formats like etc1, bc, astc and so on.
It is however perfectly possible to decode blocks of JPG on a GPU by using shader code.
Micropolygons. He said on twitter that most of the triangles are pixel sized or smaller.
This approach would fall flat on its face with large primitives:
- The for loop in the rasterizing code would get very large strides between lanes in a warp for the frame buffer memory accesses
- it doesn't parallelize across pixels in a primitive, so at its extreme, a single big triangle would be single threaded..
- A HW rasterizer has a lot more things it needs to do (compute barycentrics, keep around enough state to launch a fragment shader, etc)
- Quad occupancy. Conventional rasterizers go down to 2x2 quads as their unit to work with, because you need some neighbours if you are going to calculate derivatives for mishap selection when doing texturing. The hardware is designed around quads, and all lanes in a quad must come from the same polygon - leaving 3/4 of the hardware downstream from the rasterizer unused with single pixel polygons.
These are problems that conventional rasterizers have, but if you are writing a compute rasterizer you can conveniently skip lots of things.
In the GPU world, you have games, which are built on game engines, which are built against an API, which is implemented in a driver (which contains a compiler!), which communicates through OS abstractions with hardware, which is written in a HDL (this is where you write RTL!), which is then laid out in silicon. Now each of these parts of the stack have ridiculous complexity in them, and there are definitely things in the upper layers of the stack that impact how you want to write your RTL (and vice versa). So if your stack knowledge stops at RTL(which, honestly there is absolutely nothing wrong with!), there is still lots of fun complexity left in the stack.