I think we silently changed the default depth buffer settings & colour buffer settings to be consistent across the backends, but that’s the only thing I can think of. We barely touched OpenGL this update.

I think it has to do with this:

Fixed Span overloads not calculating the correct length value for ommitted (implicit) length parameters.

One of my goals with Silk.NET has been to avoid using unsafe methods where possible. Hopefully this serves as a minimal example.

As an example, I'm creating OpenGL buffer objects like so:

private void CreateBuffer(Span<TDataType> data, BufferTargetARB bufferTarget, BufferUsageARB bufferUsage) { Bind(); context.BufferData<TDataType>(bufferTarget, data, bufferUsage); }

With 2.16, I have no problems rendering. With 2.17, it fails to render. Changing it to the following, however, works fine and renders as expected with 2.17.

private unsafe void CreateBufferUnsafe(Span<TDataType> data, BufferTargetARB bufferTargetARB, BufferUsageARB bufferUsageARB) { Bind(); fixed(void * d = data) { context.BufferData(bufferTargetARB, (nuint)(data.Length * sizeof(TDataType)), d, bufferUsageARB); } }

(Sorry - for some reason code formatting in the comment is not updating properly for me.)
For the sake of completeness I tested against the source examples, OpenGL Tutorial 4.1, and noted only one and one half faces of the cube rendered when I modified the code to using the safe Span data method as the vertex source. Changing the package dependencies back to 2.16 it renders fine.

Hope that helps. If you need me to transcribe this into a issue just let me know.

Ah, great spot! I've opened #1397 which I propose should be released as an emergency patch provided the team agree.

Storytime:

Basically, any of the implicit count span overloads where the the length of the buffer being passed in was a multiple of its length parameter (like UniformMatrix4f, the buffer you pass in needs to be 16x as long as the length parameter you pass in) were completely broken as we just passed in the length of the buffer. In 2.17, I changed the generator such that it correctly interprets bufSize*16 to mean "the bufSize parameter is bufferSpan.Length/16". However, as part of this, I was also trying to refactor the generator such that we didn't generate those horrible in T implicit in overloads that trips up a good proportion of our userbase.

As part of this, I was refactoring the RefOverloader such that it does not operate on void* and adjusting the ImplicitCountSpanOverloader (and SpanOverloader) such that it operated on either the output of RefOverloader (as it does today) or a void*. However, couldn't make this work in a way that meant the overloader didn't take ages to generate its overloads, so I started manually reverting that refactor.

After I did this, I left one line in the ImplicitCountSpanOverloader that was still operating under the assumption that it operated on void*s, which was now never the case - we had gone back to depending on the output of RefOverloader where the parameter type would be a in/out/ref generic type parameter reference! This meant that the logic that, for void*s, will implicitly multiply the length parameter by the size of the type referenced by the generic type parameter was never being activated. So, one line changed later in #1397, this now works again.