Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1339 Excellent

About Ubik

  • Rank

Personal Information

  • Role
  • Interests
  1. This overlaps with what Matias said, but is from a bit different perspective, and I'm not someone with too much actual in-depth knowledge, but here goes anyway:   The array of blocks syntax creates several blocks, with separate binding points for each, and each of them can be backed by a completely different buffer. My intuition says indexing blocks is therefore possibly implemented very differently than indexing within a block, where arrays are actually laid sequentially in memory.   On second thought, on cards where the blocks are only 16kb at most or something similarly small, the data could be copied around in the GPU when glBindBufferRange or glBindBufferBase is called so that they end up being laid out in an array for the shader to access, but there doesn't seem to be any guarantee for that to be case.   I also just tried a very simple vertex shader with an array block, and the program crashes at shader linking in a way that hints the cause might be outside my code. The code has so far worked well in other (simple test) cases and the reference compiler has no complaints about the shader, but of course there's still a chance it's a bug in my code. (In any case, I'm running on an oldish Radeon card on Linux with the free drivers, so knowledge of this potential bug may not be very relevant to you.)
  2. There still seems to be a potential problem in the code. ShaderCompileLOG is defined to be 256 bytes long, but ShaderCompileLENGTH is passed to glGetShaderInfoLog. After the latter glGetShaderiv, ShaderCompileLENGTH will contain the actual length of the info log, which might be more than 256 bytes long! Still, the buffer given to glGetShaderInfoLog will always be just 256 bytes, so OpenGL would end up trying to write more text to the buffer than it can contain.   The easy way to fix this is to pass 256 as the maxLength parameter to glGetShaderInfoLog. Using a constant is probably a good idea to make sure the array length and the parameter stay in sync. Of course, if the log is longer than that, you will get only part of the data, so vstrakh's suggestion of allocating memory for the log text (ShaderCompileLENGTH bytes, to be exact) can be a good idea in that regard too.
  3. Apple has announced their upcoming OS X version El Capitan. Thought that it would be relevant to this thread, as it will bring support for their Metal API to OS X.   I have no details, but apparently there has been claims of 50 % improvement in performance and 40 % reduction in CPU usage.
  4. Ubik

    Vulkan is Next-Gen OpenGL

    It's nice to notice the video is recorded on a KDE desktop, hinting it's running on Linux. I suppose that also implies the demo is run with an Intel GPU. Well, I guess it's actually the video being a LunarG demo that implies it being run on Intel GPU, my understanding is that they wrote the Intel Linux driver.
  5. Seems kind of curious that using big combined buffers in pre-AZDO world has apparently not really been a thing, considering it could maybe be used to minimize state changes when editing buffer contents, if the "AZDO approach" is to use them as larger memory pools. Like, how hasn't it been a thing earlier? I guess there just isn't that much benefit (with the older GL API at least), when combining buffers of single usage type alone creates large enough blocks of memory, along with keeping things conceptually easier to grasp. Oh well, I'm not advanced enough graphics programmer to make any strong conclusions.   Anyway, I think I'll choose to have just a general Buffer type instead of artificially separated VertexBuffer, UniformBuffer et cetera (this approach actually still entices me, I'm a little bent on having strict compile-time sanity and validity checks), though mostly from the viewpoint of there being less code in general.   Thanks for your feedback!
  6. @mhagain: Good point on the new APIs revealing much about the current state of the hardware and them being largely agnostic about the buffer contents (as far as I can tell too).   @vlj: Your wording on it being forbidden by the spec somehow brought up one OpenGL-related thought I've had on background - the API may permit things, but may not actually work outside the common ways of use.   @unbird: Thanks for testing this out!   @Promit: I may very well be reading incorrectly between the lines, but I get the impression that mixing different kinds of data in single buffer (in old or current GL or D3D anyway) is not something you've done or seen done, at least enough to be a somewhat common pattern?
  7. I'm thinking of having a single Buffer concept against having a concept for each of VertexBuffer, IndexBuffer and so on, mainly from the perspective of type safety (i.e. type "Buffer" vs types "VertexBuffer", "IndexBuffer" and so on). Both OpenGL and Direct3D tell that it is possible to mix different kinds of data in the same buffer, but also say that it might come with a performance penalty. OpenGL's vertex buffer object extension text says:   But that is very old text, apparently from 2003, so it might be completely outdated. So I looked into what D3D documentation says. Here's what D3D11_BIND_FLAG's Remarks section tells:   D3D11 is from 2008, so it's documentation may be not very relevant anymore in this regard too. I don't know what would be good specific terms to find this out, and don't really have too good chances of just testing on a multitude of platforms, so am asking from you now. I guess I could ask this in two ways: 1) Is it (more often than not) a bad idea to make heterogeneous buffers (I have no idea if there is an official term for this) today? 2) Is it (more often than not) a good idea to make heterogeneous buffers today? For more specific context, I'm personally interested in how things are in current hardware (and drivers) in the PC, not mobile nor console world, but also the not so recent HW interests me. (Though I have access to one not exactly new GPU myself when I just boot up my own 'puter, to personally test things out...) My API of choice is OpenGL. But let's not restrict this only to my circumstances, it would be interesting to know how things are in general.
  8. Ubik

    Vulkan is Next-Gen OpenGL

    I imagine the vendor-specific extensions mentioned earlier could suit Apple well. Also, it might be in their interest to work with others even if they weren't as interested to actually support Vulkan themselves, to exchange ideas with others (someone cynical could use "get ideas from" there), to keep Metal at least as capable as Vulkan.   Personally I am hoping Vulkan will make the driver situation better on Linux. AMD might be interested to finally to make their drivers - the Vulkan parts anyway - open, as I suppose there is less IP baggage. I'm less hopeful with Nvidia, but who knows? Anyway, people tell their closed drivers work well, so maybe there's not that much need to open them. On the other hand, maybe the developers of the current open drivers could implement the drivers and not lag behind the spec years as it is with OpenGL. (Note that I don't mean to disrespect their work by that wording.)
  9. Ubik

    So Many Texture Units!

    I'm not Vincent_M, but that number can be found from the OpenGL API documentation. (The linked documentation pages are current/for 4.5.) On the page of glActiveTexture it is said that the number of texture units must be at least 80. The page also refers to glGet's GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, for which the value must be at least 48. (The per stage minimums are 16.)
  10. Models done in a "polygonal style" may very well have lots of faces that have more than three corners. It's easy to imagine spaceship or station models having lots of four-sided faces and it's not a big stretch to come up with designs with more complex flat surfaces. Still, if the models are simple and few enough, it really might not matter much at all.
  11. It might even make some sense for Khronos to have some kind of "low-level GL" specification alongsinde OpenGL, because that way the latter could have an actual cross-platform and cross-vendor implementation built on the former. Then the folks who still want or need to use OpenGL would have to fight against just one set of quirks. Well, as long as the LLGL actually had uniformly working implementations...
  12. Ah, so it's more like different handlers for different tasks instead of three general-purpose units, though by the sound of it it's not even that clear with the distinction between drawing and computing. The latter was for whatever reason my first assumption. From that perspective it felt reasonable to think that there would be no reason to be more of them than there are CPU cores to feed them with commands. Teaches me to not make quick assumptions!   Thanks for taking the time to tell about this. Even though I obviously haven't delved into these lower level matters much, they are interesting to me too.
  13. Good clarification. Makes sense that even if the GPU has lots of pixel/vertex/computing units, the system controlling them isn't necessarily as parallel-friendly. For a non-hw person the number three sounds like a curious choice, but in any case it seems to make some intuitive sense to have the number close to a common number of CPU cores. That's excluding hyper-threading but that's an Intel thing so doesn't matter to folks at AMD. (Though there's the consoles with more cores...)   I'm wishing for something nicer than OpenGL to happen too, but it's probably going to take some time for things to actually change. Not on Windows here, so the wait is likely going to be longer still. Might as well use GL in the mean time.   Creating resources or uploading data on a second context is what I've mostly had in mind earlier. I did try to find info on this, but probably didn't use the right terms because I got the impression that actually parallel data transfer isn't that commonly supported.   I've now thought that if I'm going to add secondary context support anyway, it will be in a very constrained way, so that the other context (or wrapper for it to be specific) won't be a general purpose one but targeting things like resource loading specifically. That could allow me to keep the complexity at bay.
  14. Alright, I honestly hadn't expected this to be so clear-cut. A bit sad and maybe a little ironic too that GPU rendering can't be parallelized from client side too, with OpenGL anyway.   Thank you for sharing the knowledge!
  15. I have wanted to support multiple contexts to be used in separate threads with shared resources in this convenience GL wrapper I've been fiddling with. My goal hasn't been to expose everything it can do but in a nice way, but the multi-context support has seemed like a good thing, to align the wrapper with a pretty big aspect of the underlying system. However, multithreaded stuff is hard, so I finally started to question if supporting multiple contexts with resource sharing is even worth it.   If the intended use is PC gaming - a single simple window and so on (a single person project too, to put things to scale, and currently targeting version 3.3 if that has any relevance), what reasons would there be to take the harder route? My understanding is that the benefits might actually be pretty limited, but my knowledge of all the various implementations and their capabilities is definitely limited.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!