• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1839 Excellent

1 Follower

About cgrant

  • Rank

Personal Information

  • Interests
  1. Driver may not be smart enough, or just make the lazy assumption that all shared resources must be sync on context switch whether or not they are dirty. If this worked previously without issue then its most likely a driver change that brought about the issue.
  2. To add to what others have mentioned, the description you gave in lacking any meaningful info for other to provide/suggest a solution. 1. How was timing done? I keep mentioning this in every other beginner post. FPS is NOT a good performance metric. Give us absolute clock time...meaning seconds, milliseconds, nanosecond 2. Where or what is FloatBuffer and how is it implemented? 3. What does your shaders look like ? 4. What does your rendering pass look like? Too many unknown..if what I'm trying to get at.
  3. If you have shared resources( implied given that you are using shared context ), then the driver have to ensure a consistent view of each resources when each context becomes active. The only way to do this is through some form of synchronization which I think others have pointed out. This goes for all shareable resources...iirc the specification points this out to. Without this automatic 'synchronization' the driver cannot be ensure coherency as with what you mentioned its possible that one context may be modifying the resource while one another is reading it( which means a multi-threaded setup). If you are not using multiple thread, then having multiple context really makes no sense...as a single context would work fine since each window will supply its own device context which is all that *MakeCurrent cares about. Even in this case there will still be a price to pay for calling *MakeCurrent when switching windows. If you application is multithreaded then there is no need to call *MakeCurrent more than once to initialize the context on that thread as once that association is made it never changes unless you manually call *MakeCurrent on the SAME thread with a different context.
  4. COM Interface best practices

    I think the common practice was bullet point #3 wherein you use the least common denominator and then fetch the latest interface if required.
  5. FBO are basically free as it just a 'name' OpenGL object. FBO attachments are not as textures or render buffer requires memory as well as a name. So you are not really saving anything using just a single FBO. With that said, did you profile the code to see if there is even a need for this 'optimization' ? Although I don't recall the specs going over the solution you propose, the attachments are a part of the FBO state so I'm going to say this is undefined behavior aka it does not work consistently aka don't do it. The specs explicitly call out reading and writing to the same attachment as not allowed as it creates a feeback loop.
  6. Don't have any links to share right now, but I've experience cases ( I want to say on AMD HW ) in the past where the texture parameters would not reflect unless specified before the call to create the texture store. That is not to say the texture would not display as the default params would be enough. A quick test would be to change the filtering/wrap mode to see. However, if all is working well for you then now worries then.
  7. Why are you limited yourself to 2 threads? I'm currently working on my editor using the Sony ATF framework ( WinForms version ) and with that application idle message pumps the 'main thread' as this is the thread that does all the rendering. The UI does not block and should not block unless you like being frustrated. Whenever a drag and drop operation is performed a loading task is issue which perform the resource loading. Resource loading happens in different phases and is fully threaded. -File I/O. If the resource is a graphics resource then dispatch additional task to load the graphics resource. There is nothing stopping you from creating additional OpenGL context on other threads to do the loading. -If the task does not require graphics resources then a callback is scheduled to indication its completion. There is a lot of specific details that I left out as they are more or less related to my current specific architecture. I do admit it was a little tricky getting the drag and drop behavior to work ( most sync issues ). However, without a proper thread/multithread/task system in place you are going to find yourself just hacking stuff to pieces. Like others have mentioned though, editors for the most part are not realtime in the sense that runtime performance should be a mode of the editor vs being the actual editor. If that is not the case then what you seem to be aiming at is an in-engine editor which you alluded to having a separate design plan for that. Why would you want them different ? Wouldn't that be doing twice the work ? My approach that I touched on above utilized the same framework that the actual application built using the editor would use and so far I cannot complain.
  8. Side note, your texture parameters must be specified before creating the actual texture with any glTexImage* functions.
  9. Just to be pedantic..4K as I think its being used here has nothing to do with GPU supported texture resolution as that is a HW limitation. Most modern GPU are capable of support 16K textures, but as mentioned, this large resolution texture comes with a price.
  10. I did miss that 2D part, but yeah the only sane way you are going to get by is to do so form of scaling from your default resolution. Still think there will be some distortion, as even though the app is rendered at resolution X, the native display has a specific resolution ( can be queried ). You can go the route of having assets for a few common resolution ( gotta do the research ), or redo your asset so that they correspond to some other metric, ex. aspect ratio, instead of fix resolution. Does your app works at any other resolution than 1024 x 768 currently ? If not, can you say why ?
  11. Why would you off the bat limit the resolution of you application with no indication as to why this would be help. If its just for the sake of let say running on a PC then this is not optimal. Most framework these days( most likely SFML ) have the ability to enumerate the device capabilities, using that as your starting point would present a more flexible design. If it turn out that the specific resolution is too high to support your application feature, then you can use the said result(s) from enumeration to dial back resolution. Also, if you get caught up on resolution you will soon find this to be a pain, there is no such thing a mobile resolution especially on Android where the device and so wide and varied.
  12. DX12 Overlay in DX12?

    Drawing overlay UI elements is would be no different that drawing any other object...A draw is a draw, ie. the API has not understanding of what you are drawing...all it sees are buffers, shaders, pipeline state etc... So yes you would have to all the setup required to render you overlay.
  13. Which API to learn first

    Did they stop supporting OpenGL ( kinda find that hard to believe, as this would force all legacy application to have to update ), or they just don't support any version greater than 4.2?
  14. Which API to learn first

    APIs are just a means to an end, in this context a way to express certain graphics algorithm and concepts. With that said wrt to what graphics API to learn first, I'll keep my bias out it and go with the recommendations already given. However, before you delve into API ( which are useless by themselves ) how is your understanding of the basics: -3D maths -Lighting. -Shaders ( not the actual implementation( API specifics), but the concept of ) ... Without having a basic understanding of these, you will find that you will be fighting a battle on 2 front, on one hand the basic concepts, on the other hand API itself.. The two are NOT one and the same.
  15. If you want to learn about graphics techniques, then you need to learn the basics about 3D graphics/rendering and not OpenGL. There is a lot of confusion as to the difference between an 'graphics' API and graphics techniques or graphics rendering API or graphics rendering. The two are NOT the same. OpenGL is just an API and nothing more so if you want to learn OpenGL all you will end up learning is just how to interact with the API ( just making API calls ). However, what you do with the API is a whole different matter. Do not get hung up on a specific API as once you have the basic down however you choose to express what you've learn then become a matter or personal/business preference. Meaning, it will not matter what you use OpenGL, DX, Vulkan, Metal etc..they are all API and useless by themselves without direction, direction being the expert/not so expert application of graphics rendering/compute techniques.
  • Advertisement