5 ms·

That's very exciting! A nit: > For example, I have not encountered hardware for reading vertex attributes or uniform buffer objects. The OpenGL and Vulkan sp

That's very exciting! A nit: > For example, I have not encountered hardware for reading vertex attributes or uniform buffer objects. The OpenGL and Vulkan specifications assume dedicated hardware for each, so what’s the catch? That is not my understanding of those specs (as someone that's written graphics drivers). Uniform Buffer Objects are not a "hardware" thing. They're just a way to communicate uniforms faster than one uniform per API call. What happens on the backend is undefined by those specs and is not remotely tied to some hardware implementation. Vertex Attributes might have been a hardware thing long ago but. I'm pretty sure there are older references but this 9yr old 2012 book already talks about GPUs that don't have hardware based vertex attributes. https://xeolabs.com/pdfs/OpenGLInsights.pdf https://xeolabs.com/pdfs/OpenGLInsights.pdf chapter 21

M277 6y ago
This is completely off topic, I am very sorry, but given your comment and your username -- are there any learning resources you would particularly recommend for graphics programming? I have collected a few already (however they are all beginner level), and was wondering if there are hidden gems I missed.
- majjam 6y ago
  not op, but here are a few ive collected: https://web.archive.org/web/20130517222528/http://www.arcsynthesis.org/gltut/ https://web.archive.org/web/20130517222528/http://www.arcsyn... https://news.ycombinator.com/item?id=26017086 https://news.ycombinator.com/item?id=26017086 https://news.ycombinator.com/item?id=18840859 https://news.ycombinator.com/item?id=18840859
- dlivingston 6y ago
  An excellent starting point for anyone interested in low-level graphics programming is Sokolov’s tinyraytracer [0]. It’s also a great way to learn a new language (work through the code while porting it to $DIFFERENT_LANGUAGE). [0]: https://github.com/ssloy/tinyraytracer https://github.com/ssloy/tinyraytracer
- nextaccountic 6y ago
  Here's a free book on physically based rendering https://www.pbr-book.org/ https://www.pbr-book.org/
sharpneli 6y ago
I agree with the nit. > Simply put – Apple doesn’t need to care about Vulkan or OpenGL performance. OpenGL and Vulkan allow an implementer to more easily make such specialized HW. But it doesn't assume it at all in any other way. If your HW is fast enough there is absolutely no need to implement specialized block for it without any performance penalty. It's trivial to implement things like input assembler without specific HW, just issue loads. But it would be massive pain to go the other way around. Try to sniff what loads fit the pattern that could be tossed into fixed function input assembler. That's a no go. This is the right way around to do things. As there is no performance penalty for "emulating" it, because there is nothing to emulate in the end.

M277 6y ago

This is completely off topic, I am very sorry, but given your comment and your username -- are there any learning resources you would particularly recommend for graphics programming? I have collected a few already (however they are all beginner level), and was wondering if there are hidden gems I missed.

majjam 6y ago
not op, but here are a few ive collected: https://web.archive.org/web/20130517222528/http://www.arcsynthesis.org/gltut/ https://web.archive.org/web/20130517222528/http://www.arcsyn... https://news.ycombinator.com/item?id=26017086 https://news.ycombinator.com/item?id=26017086 https://news.ycombinator.com/item?id=18840859 https://news.ycombinator.com/item?id=18840859
dlivingston 6y ago
An excellent starting point for anyone interested in low-level graphics programming is Sokolov’s tinyraytracer [0]. It’s also a great way to learn a new language (work through the code while porting it to $DIFFERENT_LANGUAGE). [0]: https://github.com/ssloy/tinyraytracer https://github.com/ssloy/tinyraytracer
nextaccountic 6y ago
Here's a free book on physically based rendering https://www.pbr-book.org/ https://www.pbr-book.org/

sharpneli 6y ago

I agree with the nit. > Simply put – Apple doesn’t need to care about Vulkan or OpenGL performance. OpenGL and Vulkan allow an implementer to more easily make such specialized HW. But it doesn't assume it at all in any other way. If your HW is fast enough there is absolutely no need to implement specialized block for it without any performance penalty. It's trivial to implement things like input assembler without specific HW, just issue loads. But it would be massive pain to go the other way around. Try to sniff what loads fit the pattern that could be tossed into fixed function input assembler. That's a no go. This is the right way around to do things. As there is no performance penalty for "emulating" it, because there is nothing to emulate in the end.