Patch cylinder draw bug in Orthoview: Cause found, nVidia support [1506400]

[Bikerdude]

Morning taffers

 

As refernce the following post's, I logged a support call with nVidia

 

- http://forums.thedar...__1#entry343771

- http://forums.thedar...561#entry340561

 

Got an email back from nVidia -

 

Our development team concluded their investigation of this issue. This in an application bug caused by a backward incompatible change between the OpenGL 4.3 and OpenGL 4.4 specifications that introduces GL_MAX_VERTEX_ATTRIB_STRIDE. The application creates a default OpenGL context that defaults to OpenGL 4.4 in recent drivers and when calling VertexPointer with stride 25160 hits the GL_MAX_VERTEX_ATTRIB_STRIDE limit set to 2048.

 

For the record the bad code is here https://github.com/o...rables.cpp#L100 and ArbitraryMeshVertex is defined here https://github.com/o...aryMeshVertex.h. Our development team will reach out to the developers to report this issue and our findings. Hopefully this can be resolved with a patch in the future by the Dark Mod team. Let me know if you have any further questions.

 

@Orbweaver are you still maintaining DR atm as we need someone that nVidia can speak to etc, otherwise Greebo can you help if Orbs dosen't get back to me?

[OrbWeaver]

It's been a long time since I touched that code but I can have a look. It seems that nVidia have done most of the work to actually identify the problem at least.

 

I don't immediately understand why ArbitaryMeshVertex would have a size of 25160 though. By my count it includes 17 floating point values, which should come to 68 bytes.

[greebo]

Thanks for the heads up. Nice move of nvidia support to actually dive into the codebase identifiying the issue.

 

As OrbWeaver said, I don't see why ArbitraryMeshVertex's sizeof should report >24 kB, but we can at least try to reproduce it. I don't know if I actually can do that, since I own graphics hardware from 2010.

[Bikerdude]

Thanks guys,

 

@Orbs do you have an nvidia card or do you need to borrow one..?

@Greebo what card do you have atm..?

[OrbWeaver]

I have an ATI card myself, but if nVidia support are correct and there is something screwy going on with the stride parameter, then hopefully it will be possible to debug in a hardware-agnostic way.

 

It's also possible that there is an issue with the heavily deprecated non-VBO-based vertex data submission code. Updating it to use VBOs always (even if it isn't particularly efficient with regard to maintaining and updating data only when necessary) should work on any version of OpenGL since 1.5, and may solve this and other issues on newer drivers.

[Bikerdude]

Well I have a GT640 that I use as a physx card that i can lend you if need be.

[OrbWeaver]

Well I have a GT640 that I use as a physx card that i can lend you if need be.

 

I'll bear that in mind, thanks. My machine at work does have an nVidia card so hopefully I will be able to reproduce this myself.

 

In any case, I think the line of code linked by nVidia support is incorrect. I suspect the cause of the problem is this block of code in RenderablePatchWireframe:

 

  const ArbitraryMeshVertex* p = &m_tess.vertices.front();
  std::size_t n = m_tess.m_nArrayWidth * sizeof(ArbitraryMeshVertex);
  for(std::size_t i = 0; i <= m_tess.curveTreeU.size(); ++i)
  {
	glVertexPointer(3, GL_DOUBLE, GLsizei(n), &p->vertex);
	glDrawArrays(GL_LINE_STRIP, 0, GLsizei(m_tess.m_nArrayHeight));

 

Here the stride is being increased with the number of subdivisions on the patch, which is obviously going to cause problems when the number of patch vertices increases the stride past the maximum expected value.

[Bikerdude]

It would make sense that you understand DR's code more than the nVidia chaps, so if you need me to do any testing let me know etc. In the meantime I got another email from the nVidia support chap I hve been taling to -

 

I'll make sure to past this thread along to the developer in case he wants to chime in.

 

Thanks,