First off since you mention you are learning, do yourself a favor and if you really want to learn opengl, get yourself in a situation where you can limit the frustration of having to do setup code, and provide yourself with an environment that can help you debug. THIS IS NOT MAC OSX. Ubuntu or Windows + Clion or VS + GDEbugger + common support libraries like Glew, GLFW and SOIL help you get a window and load textures quickly (just a hypothetical example)
Also, as has been suggested before, there is very much an old way and a new way of doing things in OpenGL, and they have big implications on performance.
Luckily, An Nvidia guy has a github page that has sample code for the new way of doing things. I highly suggest you clone that repo and study it religiously.
That github page, paired with study of the opengl spec that describes the features in that code, will IMO be your best bet at learning opengl.
In a nutshell... the movement in the OpenGL API has been that of 0 driver overhead. That is, the application does some of what the driver usually does and thus the driver does less work, so you can really slim down the runtime graphics stuff.
Lastly, in the repo is a solution to packing multiple textured quads using (might not have the right names) ARB_BUFFER_STORAGE, SHADER_DRAW_PARAMETERS, BINDLESS_TEXTURE_ARB, SPARSE_TEXTURE_ARB, and MULTI_DRAW_INDIRECT. Again, the application is doing what the driver might do, thus reducing overhead. If you think of a draw call as packing data of similar objects as opposed to actually drawing a single object, you begin to see how the transition of old opengl to modern opengl is themed.
Phew, I grossly misunderstood bindless texturing. Residency is only for the texture handles. Sparse Texture support is for residency of texture memory. Luckily the two work together quite well, so if I add sparse texture immutable storage I can leverage the same querys of determining bindless residency to deal with sparse residency.
Parts of Unity are incredibly frustrating. Serialization is poorly documented and is inconsistently implemented, the GUI sucks, and the editor can get out of hand quickly with large projects.
However, It is rather strange that your game dev teacher is talking about unity from the perspective of a player when your teacher is a developer yes?
Also, before GDC with UE4 and CryEngine, consider what options you had before unity? They were far and few between, and Unity sure beats writing your OWN engine.
Now of course this could limit you if your game doesn't fit well with what Unity provides. There is a statement that is made often on these forums "Make games, not engines". products like unity exist so that small teams or possibly 1 person that works their ass off can actually make a decent 3d game.
I agree that you should learn the underlying concepts, I would check out the nvidia opengl sdk, it has a wealth of knowledge (but you must understand that those are quicky demos and if you wanted a full engine you wouldn't mimic some of the things they do).
I also highly suggest checking out Humus' Framework3, It is a great reference for looking at the ins and outs of the various apis.
You can start in any or all of the following,
The Cg Tutorial by nvidia,
The Orange Book (GLSL), (get the latest addition)
The DirectX SDK (HLSL)
Shader model 3 (dx9) is the most common shader model you will find in hardware today.
If i recall the orange book is great for those leaving the fixed function world and entering the programmable pipeline world
Ok first step is as you are, learn to code, C++ is a good language for it, but as jump starting for beginners oriented to game development it wouldn't be my first choice.
I would advice you to begin with a more game oriented framework such as Flash ActionScript, Unity or XNA, once you have the basics of object oriented game programming you can migrate to other languages with more ease.
I agree, and I cannot stress enough how important it is to do this. These environments are controlled environments, ie. it is more difficult to cause a problem.
Unity, XNA, all provide you with a foundation for making games, a community to ask questions, and tutorials galore at your disposal. This may not be the exact technology you want to use with your game (i actually think they could be very easily you just dont know that yet, especially unity), but it is a great foundation to help you learn the basics of coding in games.
Couple this with learning C++ on the side, and you would be very surprised how fast the 2 will meet together. You will learn what classes make up a framework, what parts of a framework you REALLY like, (ie automatic asset loading from a folder on your computer) and see how you would use them in making a game. I cannot say how important this kind of knowledge is when coding a game engine of any kind.