Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
nicebyte
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
31.
▲
Introduction to Spherical Harmonics for Graphics Programmers
(gpfault.net)
4 points
by
nicebyte
6mo ago
|
0 comments
32.
▲
by
nicebyte
7mo ago
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.
33.
▲
by
nicebyte
8mo ago
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.
34.
▲
by
nicebyte
8mo ago
> 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 alloca
35.
▲
by
nicebyte
8mo ago
> 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 (w
36.
▲
by
nicebyte
8mo ago
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
37.
▲
by
nicebyte
8mo ago
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 fo
38.
▲
by
nicebyte
8mo ago
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 multipl
39.
▲
by
nicebyte
9mo ago
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://gpfau
40.
▲
by
nicebyte
2y ago
including ai generated illustrations in your articles or presentations is very cringe
41.
▲
by
nicebyte
2y ago
my comment isn't about things being written using c/make/whatever, it's precisely about the faulty assumption that complexity is needless.
42.
▲
by
nicebyte
2y ago
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 wit
43.
▲
by
nicebyte
2y ago
I bet 90% of the reason this is on the front page is the Berkeley mono font. the system itself sucks.
44.
▲
by
nicebyte
2y ago
How did you draw that conclusion from reading the contents of the link? This is a benchmark. > We evaluate model performance and find that frontier models are still unable to solve the majority of tasks.
45.
▲
by
nicebyte
2y ago
I already knew a lot of what was written here but for some reason reading this made me uninstall bumble.
46.
▲
by
nicebyte
2y ago
I was 11 or 12 when I first saw Clint Eastwood and the video + the song lived in my head rent free. Genius work, and aged well.
47.
▲
by
nicebyte
2y ago
>. they are an extremely unusual person and have spent upwards of $10,000 eh? doesn't the distilled+quantized version of the model fit on a high-end consumer grade gpu?
48.
▲
by
nicebyte
2y ago
ARM would have been a better example because the amount of people that care about RISC-V is a rounding error compared to x86 or ARM.
49.
▲
Celebrating Ten Years of Gpfault.net
(gpfault.net)
2 points
by
nicebyte
2y ago
|
0 comments
50.
▲
by
nicebyte
2y ago
It's also very funny that he decided to publish this _now_ of all times.
51.
▲
by
nicebyte
2y ago
I've lived long enough to see pg turn into a boomer-ass uncle lmao.
52.
▲
by
nicebyte
2y ago
if it makes you feel any better, it is almost impossible to do anything practically useful at all with quantum computation at the moment. this is a field for researchers, people who are okay with not seeing the fruits of their work material
53.
▲
My Gripes with Tech Talks
(gpfault.net)
3 points
by
nicebyte
2y ago
|
0 comments
54.
▲
by
nicebyte
2y ago
this really does not belong on the front page of hn > One with tools more powerful, elegant, and accessible: Linux. triple ha
55.
▲
by
nicebyte
2y ago
> D3D is clearly more integrated into the OS than Vulkan is. sure, but addressing the two points that you brought up would not entail changing windows _the operating system_, just the stuff that ships with it. you could easily ship swift
56.
▲
by
nicebyte
2y ago
I haven't laid my hands on any ARM windows devices so I wouldn't be able to tell you. I'd be somewhat surprised if the newer snapdragon stuff doesn't have vulkan support because qcom supports vulkan first-class on its gp
57.
▲
by
nicebyte
2y ago
I say this because vulkan is hamstrung by being an "open API" intended to run on a very wide range of devices including mobiles. this has major repercussions, like the awkward descriptor set binding model (whereas d3d12's des
58.
▲
by
nicebyte
2y ago
what do you mean when you say "built into the os"? d3d12 is just an api. the d3d runtime is user-space, both the UMD that wraps it and the KMD are supplied by the hardware vendor. In the end, both a d3d app and a vulkan app end up
59.
▲
by
nicebyte
2y ago
vulkan is already supported on windows as a first-class citizen by all major IHVs. I am not sure what this "adoption" you speak would entail. If you're talking about replacing d3d12, that actually is a terrible idea.
60.
▲
by
nicebyte
2y ago
> ("software" means it runs on the CPU instead of GPU) no, in this context it means that the rasterisation algorithm is implemented in a compute kernel, rather than using the fixed hw built into the gpu. so rasterization still
More ›