Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

Matias Goldberg

Member Since 02 Jul 2006
Offline Last Active Yesterday, 06:03 PM

Posts I've Made

In Topic: OpenGL 5 - Release?

27 November 2014 - 12:29 PM

Khronos is keeping the information regarding GL NG quite tight within their group members.

Normally I'd be very sceptic about it; but considering the pool of talented developers behind NG (Johan Andersson, Graham Sellers, Riccio, some Unity devs), the Mantle precedence, and the striving need for a cross platform high performance API (DirectX is no longer "enough", e.g. Android, iOS; then Metal has just a portion of the OS market; Mantle just a portion of the GPU market); I have more faith than usual.

Take in mind it is most likely GL NG will be just GL4.5 without any legacy cruft, with a unified shader compiler or IL, plus some ideas taken from the Mantle API like being multithread friendly, explicit access of DMA engines, and being multi-GPU and multi-monitor aware.

In Topic: Vertex buffer object issue

25 November 2014 - 03:47 PM

If on GL3 or newer, You should create a vao (create only once!) and bind it before the glVertexAttribPointer and glBindBuffer calls.

GLuint vaoName;
glGenVertexArrays( 1, &vaoName );
glBindVertexArray( vaoName );

In Topic: Is Microsoft changing major Kernel version again? -_-

21 November 2014 - 06:03 PM

first they change the OS name with the excuse of 3rd party software looking for 199x era strings

I'm pretty sure that was never confirmed by MS to be a reason, just something 'some dude' wrote somewhere which is now treated as truth..

I'm willing to be proven wrong of course, but naming tends to be more about long term promotional/prv/advertising than 'dumb code' if only because they could probably catch 99% of that software doing the dumb thing and spoof the return to be Win7 or whatever if needs be.

Indeed, they didn't officially confirm it.
But some dude claiming to work at Microsoft said that that was the technical reason. And a simple examination of public known source code proved him correct, there is a horrible amount of software doing bad practices. Who knows about propietary software.

Probably this is the case of someone raising the very real concern from the technical side (putting a '9' will bring us trouble!) and the marketing guys got the perfect excuse to bump the number to 10.

In Topic: Mutiple VAOs and VBOs

17 November 2014 - 08:52 PM

Over a few frames things settle down and the driver is no longer allocating new blocks of memory but is instead just handing back blocks of memory that had previously been used.  So in other words it's not necessary to do your own multi-buffering, because the driver itself is automatically multi-buffering for you behind-the-scenes.
At this stage it's worth highlighting that this buffer update model is well-known and widely-used in D3D-land (where it's called "discard/no-overwrite") and has existed since D3D8, if not earlier; i.e it has close on 15 years of real-world usage behind it.  So it's not some kind of voodoo magic that you may not be able to rely on; it's a well-known and widely-understood usage pattern that driver writers anticipate and optimize around.

Both DX12 and GL4 are moving away from this pattern and moving towards an explicit low level access memory management. With fences, unsynchronized access, and persistent mapping.

Drivers may optimize for the discard/map-no-overwrite pattern, but the higher level app. has much more information than the driver on how to deal with memory and access hazards. Driver optimizations can only go so far.
But with great power, comes great responsability.

In Topic: Mutiple VAOs and VBOs

17 November 2014 - 08:44 PM

I'm sort of having trouble understanding how mixing these could be bad. Not saying that is what you mean, but it is implied that way to me. I would think this would act as an extra safety net to the whole unsyncronized methodology.

It's not that it's bad (btw mixing both doesn't act as safety net). The thing is that you needlessly generate a problem for you when you need to render with VAOs.

The VAO saves the VBO that is bound.
If you use three VBOs, either you modify the state of the VAO every frame, or have three VAOs (one per VBO). With just one VBO but using different ranges, you need one VAO, and no need to modify the VAO in any frame.

I basically see using glMapBufferRange + the unsyncronized flag as 'Put this data in the VBO right now, I do not care how or what you do just put it in there'.

That's correct.


Which could lead to things not drawing right if you accidentally map to a VBO that is being used in drawing.

That's the best thing that can happen. The worst thing that can happen is full system crash (BSOD, or not even that, DOS-style lockup needing a hard reset). Depends on GPU architecture and Motherboard (Bus).
You must synchronize.


Note that for dynamic content (and assuming you will be discarding the whole contents every frame), you just need one fence per frame. You don't need one fence per buffer.

If I use Round Robin with 3 VBOs or more and they all get mapped with glMapBufferRange + the unsyncronized flag, I would think that the only way it would fail is if my GPU is falling behind really really badly or something is seriously wrong.

If you don't use round robin, it's the same thing. Because the example I gave you, you would be writing to a region that the GPU is not writing right now.
Remember, it's not that the VBO is in use by the GPU while you're writing from the CPU. What's important is that the dword (4 bytes) you're writing to from the CPU is not currently being read by the GPU (to avoid a crash); and that the region of memory you're writing to has already been read from all the GPU commands until now (to avoid a race condition causing graphic corruption).

Is mixing those two methods just over kill?

Yes, because you gain nothing from mixing them, and complicate yourself by having more VBOs and more VAOs.