Jump to content
  • Advertisement

Osbios

Member
  • Content Count

    50
  • Joined

  • Last visited

Community Reputation

260 Neutral

About Osbios

  • Rank
    Member
  1. Maybe this could be of use? http://oss.sgi.com/projects/ogl-sample/registry/EXT/import_context.txt "This extension allows multiple X clients to share an indirect rendering context."
  2. Osbios

    help open gl code

    hi please transfer money to this account in Attachments for making me rich
  3. Time for science again. Run some simple test with mass draw calls and changing buffer and texture IDs. And after every draw call read out that IDs via glGetIntegerv. Could only messure ~1% difference in performance one mesa and the AMD blob drivers on windows7.
  4. One more thing, your "DSA"-like getter setter thing. First of all glGetIntegerv should not be used in performance code paths. Not sure how the intel drivers exactly behave but in case of nvidia and amd it would sync your application thread and the driver thread and that is very bad for performance. You should exclusivly send information to OpenGL (except initialisation and debuging), and for data streams (e.g. reading out images or buffers to the client) only after fences get signaled. Just store the current status yourself somewhere. Just try to not use anything that asks OpenGL for values.
  5. If even glBufferSubData has the issue and you are 100% sure your update data is ok then this is clearly a driver bug. Did you try to install a current intel driver by yourself already?
  6. If you (miss-)use mipmaps you do not get very much out of it for making it more complicated. 33,3_% to be exact. And you can hardly make full use of the smaller mipmap levels. My question would be if you really need more then a 2048x2048 texture for what you draw as ordered billboards? The only thing you normaly draw ordered without depth write are alpha transparent objects. And everything else (including stencil transparency) can be drawn before that with depth write enabled. So you can sort for texture affiliation and only need to bind each texture once per frame.
  7. Also your render thread with the gl context does not have to be a windows even thread.   Thats actually even worse then multiple threads each with its own context. EDIT: I read the QT docs and they use a full blown context. So I would strongly advice to not use that!
  8. OpenGL is fundamently anti threading on the client side. Sure it makes sense to use threading for a few things like big data transfers from or to the client side or shader compilation (thats really more about sync objects, and having a seperate context for the independent sync signal). I tried to make usable threaded interface for OpenGL but there are just to many non shared objects (Even bindless texture handler states ARG! :[ ) and also the stupid behavior that you can't create sync objects without at the same time inserting them into the work queue. I would just make one render thread. And use threaded helper functions for the few casses where it makes sense. Also VAOs are slower except for MESA based drivers. Using old style binding and if available GL_ARB_vertex_attrib_binding and GL_ARB_multi_bind will be faster on AMD and Nvidia blob drivers. In that case you don't even use non-shared objects.
  9. glGetUniformLocation gives you the location. And then you can use the location to set/get the binding via glUniform1i / glGetUniformiv.
  10. glGetUniformLocation and glUniform1i/glProgramUniform1i should work just fine like with textures. Is your shader actually using the image in a way that it changes the output? Otherwise the glsl compilers are free to optimize it away. And then any kind of query won't find it in the gl shader object and glGetUniformLocation will return -1!
  11. Osbios

    Trouble displaying texture with SOIL (newbie)

      There is still no need to use RGB as internal format. Best is always something like a 1, 2 or 4 component sized format like GL_RGBA8. The drivers internaly use RGBA for RGB formats anway. And some of the "newer" gl functionalities (e.g. image load store) do not even support unsized and/or RGB formats.
  12. Osbios

    Converting to OpenGL 4

    If you only want to get a big 2d pixel array to the screen your current code is just fine from a performance standpoint. With OpenGL or D3D11 you can't access texture data directly and always neet to use a api copy command to get data into a texture before you can then get that texture onto the screen. Only D3D12 and Vulkan give you the abbility to draw directly from client memory to the screen. If you do blitting, like put you scene together by drawing many square images (sprites). Then it may be already worth to consider a more modern approche. Edit: I hate forums that fuck up formating if your don't use javascript. -_-
  13. Osbios

    pixel offset after rendering to fbo?

    Try this. vec2 res = textureSize(bgl_RenderedTexture, 0); texCoord = texCoord * (res / (res + 1.0)) + (0.5 / res); Untested!
  14. One nice way is to design a interface/API for some underlaying library or tools in such a way that you can optimize the hell out of it... later.   Just make the interface really nice. The backend code can be the most horrible piece of shit as long as at works reasonable enough for now.
  15. The limit of functions that take GL_TEXTURE_0 + i as parameter (e.g. glActiveTexture) is [0..GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS-1]   So if GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is 2 you only can use GL_TEXTURE_0 and GL_TEXTURE_0 + 1 (or GL_TEXTURE_1). But non stone age hardware has way more texture slots.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!