centurytree.blogg.se

1. #Is opengl 4.4 or 4.5 better how to#
2. #Is opengl 4.4 or 4.5 better update#
3. #Is opengl 4.4 or 4.5 better driver#
4. #Is opengl 4.4 or 4.5 better software#

I read about how “Stateless/bindless OpenGL is the future”… but can I use this right now? Or can I at least design my current API with the future in mind? If so what should I do to kind of wrap “Both current and future OpenGL behaviours” together? (I suppose I should just simply use the future API right now and try to emulate it in terms of the current API, right?) So I need to make my own as there isn’t anything good enough out there, for what I need. So… where is a good place to start… if I want to make a game engine? I want my game engine to be all about space… outer-space, the stars, planets, etc. I have a question for you… as a beginner to OpenGL… but actually I’m an expert outside of OpenGL (wrote my own compiler and far harder things than that)… I really appreciate all your in depth insight into OpenGL and from the perspective of someone who wants OpenGL to not suck… So obviously bindless only will not happen for obvious technical reasons.

#Is opengl 4.4 or 4.5 better update#

Update 02: I’ve been informed that at the time of date only 2 IHVs support bindless (the 3rd major one on desktop doesn’t) and I forgot GLNext targets mobile as well. tex A goes in tex unit 0, tex B goes in tex unit 1) into immutable unique tables where in D3D11 these tables call the appropiate set texture units and in GLNext the table just binds the UBO that is already filled in GPU with the necessary handlers.

#Is opengl 4.4 or 4.5 better software#

Backwards compatibility can be achieved in software by keeping permutations of textures needed by a material (i.e. It’s great, and I love the idea of explicitly controlling texture residency.

#Is opengl 4.4 or 4.5 better driver#

Shared contexts is AFAIK not very thorough on the standard, making it a wild west of what works and what doesn’t depending on each implementation whims and furthermore since the GL std isn’t multithreading aware, there are no ways for us to help with the synchronization, forcing the GL driver to lock much more frequently than it should. Yes, this sounds very much like the failed deferred contexts or D3D12’s bundles. The only ones that require locking the main thread are buffer creation and mapping/unmapping (and textures). I can create, map buffers, validate commands, compile shaders from within these threads and then in the main thread append all the commands that have been queued in the other threads into the main one. Let me create an “object-context” per thread, child of the main GL context which I can use for each thread.

#Is opengl 4.4 or 4.5 better how to#

OpenGL 4.4/4.5 is quite good, but you don’t know how many people just doesn’t know how to use it correctly because the tutorials are all mixed up.

I don’t want to google “OpenGL 5 how to do ” and find an article from 1997 among the top 10 (based on a true story) or find snippets of code that would obviously break in 5.0 but worked fine before 4.0 (specially if Khronos actually delivers on my no-hazard tracking request!). Fix the need to create a GL context to get the true GL context fiasco (to get wglCreateContextAttribsARB…).Standardized Multi-GPU support is a plus.

mapped” I mean the model (that there is no hazard tracking in GL4 for those types of mapping), not that everything must be persistent mapped. Update: Clarification, by “treat everything as it if were persist. Treat everything as if it were persistent mapped/unsynchronized mapped. Just leave one (the superior one, glTexStorage)