nicebyte

For future, try to post the actual code (i.e. text) instead of screenshots of code - will make it easier for people to copy/paste snippets if they want to help you out.

> I guess ill save any serious attempts at multi-threading for Vulkan then, is that the conclusion i should be leaving with? Yeah I would recommend that. Focus on the fundamentals and try not to get too bogged down in the api details yet.

to drive the point home, the opengl backend of my homegrown gfx lib is ~2000 lines of code Is the vulkan one is about the same size now, but it's nowhere near being feature complete AND i've "outsourced" gpu memory management to AMD's VMA library (which could easily add anothe 1K lines if i did it myself). I definitely don't want to discourage anyone from learningVulkan, but those who are considering need to understand that graphics APIs are not about graphics, they are about abstracting the GPU. Learning DX12 or Vk will take a nontrivial amount of time during which you will not be dealing with actual "graphics", i.e. making pretty images. Instead, you'll be figuring out how to be efficient at feeding data into a massively parallel computer attached to your regular computer this can be interesting in and of itself, but make sure you understand what you're getting into!

That just sounds that you're calling OpenGL on a thread with no active OpenGL context. However, in general, it is barely possible to get an appreciable speedup from an OpenGL renderer by using multithreading. Don't hope that you can, for example, call the shadow map rendering commands on one thread and scene rendering commands on the other - that will not work: the opengl driver will just synchronize those threads and everything will effectively become serialized, losing any benefit you may have had from parallelism. This isn't a question of driver quality, it's a fundamental constraint caused by the design of OpenGL. So, you're better off calling OpenGL on just one thread. One exception to this is loading textures/meshes etc from disk. Since most time is spent waiting on file reads it makes sense to split resource loading/texture and buffer creation into a separate thread(s) - create a shared context on the resource loading thread, load your textures/models on it while you do other stuff. This could improve your loading times. If you are interested in building a multithreaded renderer, the best path forward is with new APIs - DX12 or Vulkan. They allow to split the driver overhead of recording command buffers onto multiple different threads, thus making better use of you cpu's many cores. This comes at a price of needing to handle GPU-side synchronization and memory management yourself though - it is a very daunting task and I don't think someone who is beginning graphics should bother with it. I promise you it's way more fun to play with lights and materials than to look for synchronization bugs in your vulkan code

What exactly do you mean by "refer to play/pause function"? If you mean "how to trigger play/pause programmatically", you can try using AutoHotkey (https://www.autohotkey.com). Assuming you have Windows, a quick setup could be something like: 1. The Arduino runs a simple piece of code that simply detects a physical button press. Once the button is pressed, it sends a message to serial output via `Serial.print` 2. On the computer, you run a simple Python script that listens to the the serial (using python's builtin `serial` module), and triggers an autohotkey script when a message arrives from the arduino. 3. The autohotkey script emulates a press of the media play/pause key (`Send {Media_Play_Pause}`). This should work in all the desktop apps that properly handle the media key presses. Unfortunately it's not trivial to make it work in the general case. For example, it will NOT work with youtube as it does not handle the media keys. You will likely have to implement specific hacks if a particular app you want to support doesn't handle media keys. EDIT: forgot to mention that all of this assumes that your arduino is going to be connected to the computer via USB. Other methods of communication will be more involved.

OpenGL ES is just a version of OpenGL for mobile devices. I would not say that it is simpler. Later versions of OpenGL ES (3.1+) supported by more powerful devices like adreno 630 are getting close in terms of capabilities to the desktop counterpart (i.e. 3.2 has compute shaders). Earlier versions (GL ES 2.0) have a smaller API surface, however they have limited capabilities, making it harder to do certain things (and effectively sometimes forcing you to have two different paths if you want to support older hardware). GL ES 2 market share has been shrinking though.

If you do decide to go the CMake route, look into the `add_custom_command` directive. You can get glslangValidator binaries from the Khronos website (https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/) or just compile it from source (https://github.com/KhronosGroup/glslang). I could post a snippet from my own cmake file here however, it won't work for you because my setup is most likely different from yours. If you try it and get stuck, just post here, maybe i'll be able to help.

Recommended books on programming and computers in general: CODE by Charles Petzold (should be required reading for any CS course, honestly) nand2tetris Recommended books on C++: Effective Modern C++ by Scott Meyers C++ Primer by Lippman et al (make sure to get the latest edition) The Design and Evolution of C++ by Stroustroup Recommended books on computer graphics: Peter Shirley's raytracing series ("Ray Tracing in One Weekend", etc.) - those are available for free online (http://inonewekend.blogspot.com) More advanced reading: Physically Based Rendering by Pharr et al. (also available for free online: http://www.pbr-book.org) Realtime Rendering (http://www.realtimerendering.com)

If you're using visual studio and cmake, it's possible to pre-validate your shaders with glslangValidator as part of the build (that's what I do). It reports shader compile errors within the IDE (not in realtime though, only when you build) before the application has the chance to run and show you a black screen ? In a pinch, you could try using http://shader-playground.timjones.io (just make sure to pick GLSL as the source language). It has the added advantage of showing you the generated SPIR-V or DXIL (in case you want to explore that), and ability to chain different tools together (like putting generated SPIR-V through SPIRV-Cross).

I wrote this before realizing that might not have been what OP meant. Gonna leave it here since it seems I can't delete my own post:

How limited are we talking? In my opinion, there's a big difference between "no experience whatsoever" and something like "wrote some lua script for WoW one time", for example. It's always intimidating to start from zero. That being said, the course looks like it aims to get students over the basic hurdles of getting a dev environment set up and writing and running simple programs. Most of these things will be straightforward and won't require a lot of thinking; the course will just slowly ease you into the programmer mindset. Of course, a lot depends on the instructor as well, but I think you'll be fine even if you've never programmed before.

Smartphone GPUs can also have their own instruction sets (I know for a fact ARM Mali does). I haven't seen any public documentation for them, however, unlike for AMD GCN etc.