Author Topic: go_even_faster  (Read 20679 times)

0 Members and 1 Guest are viewing this topic.

Offline niffiwan

  • 211
  • Eluder Class
Quote
In both cases the game exits at normal speed (i.e. <1 sec).  In addition, the in-mission framerate is also faster - approx 6fps worst case compared with approx 4 secs per frame worst case.

As I said, new collision code is using STL hash map. STL doesn't run very well in Debug I noticed which has gradually been problematic as the code base continues to use STL containers in more parts of the code. Probably something that warrants us looking into ways to get STL containers faster in debug. But that's not within the scope of this thread.

OK - FSO running slow in debug isn't a bit deal to me (it's expected behaviour, right?  ;)), waiting 15 mins for it to exit kinda is though - although I haven't really seen any drawbacks to just killing it off - so that's probably an OK workaround.  It'll probably confuse a normal user trying to generate a debug log though.

I suspect that the function below is causing the problem, the entire file is wrapped in an #ifdef SCP_UNIX so you probably won't have seen the issue on Windows. There's a linked list (RamTable) keeping track of all the allocated memory and its size, with the old collision code RamTable has a max size of approx 19,000 entries, with the new collision code I've seen it as high as approx 263,000 - and that function has a woefully slow way of finding the pointer of memory it's looking for.  When the list is around 263,000 entries in size, it was taking approx a minute to remove 1000 entries from the list - obviously it gets faster and faster as you remove more and more entries.   I'll see if I can re-factor it to be more efficient when dealing with large number of entries.

tl;dr doesn't seem to be a problem with the new collision code itself, it's just triggering a different issue in debug.

Code: (code/windows_stub/stubs.cpp) [Select]
#ifndef NDEBUG
void _vm_free( void *ptr, char *filename, int line )
#else
void _vm_free( void *ptr )
#endif
{
    if ( !ptr ) {
#ifndef NDEBUG
        mprintf(("Why are you trying to free a NULL pointer?  [%s(%d)]\n", clean_filename(filename), line));
#else
        mprintf(("Why are you trying to free a NULL pointer?\n"));
#endif
        return;
    }

#ifndef NDEBUG
    RAM *item = RamTable;
    RAM **mark = &RamTable;

    while (item != NULL) {
        if (item->addr == (ptr_u)ptr) {
            RAM *tmp = item;

            *mark = item->next;

            TotalRam -= tmp->size;

            free(tmp);

            break;
        }

        mark = &(item->next);

        item = item->next;
    }
#endif // !NDEBUG

    free(ptr);
}
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Echelon9

  • Moderator
  • 210
Swifty, I agree that patch is integrated, but it is no longer having the previously observed effect of fixing the compile error.

Possibly something else has changed in that area?

Try removing all the preprocessor directives and the non-APPLE function pointers so you only have this

Code: [Select]
typedef void (* glDrawElementsBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawRangeElementsBaseVertex) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawElementsInstancedBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (* glMultiDrawElementsBaseVertex) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);

See if it compiles.

It work successfully if the follow section in gropengl.h comments out the #ifndef GL_ARB_draw_elements_base_vertex section:
Code: [Select]
/*#ifndef GL_ARB_draw_elements_base_vertex
#define GL_ARB_draw_elements_base_vertex 1*/
#ifdef __APPLE__
typedef void (* glDrawElementsBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawRangeElementsBaseVertex) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawElementsInstancedBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (* glMultiDrawElementsBaseVertex) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);
#else
typedef void (APIENTRYP PFNGLDRAWELEMENTSBASEVERTEXPROC) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (APIENTRYP PFNGLDRAWRANGEELEMENTSBASEVERTEXPROC) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (APIENTRYP PFNGLDRAWELEMENTSINSTANCEDBASEVERTEXPROC) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (APIENTRYP PFNGLMULTIDRAWELEMENTSBASEVERTEXPROC) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);
#endif // __APPLE__
//#endif // GL_ARB_draw_elements_base_vertex

i.e. it's not an issue with the correct branch selection upon #ifdef __APPLE__, but the earlier check if GL_ARB_draw_elements_base_vertex is defined.

Could this because of also having at code/graphics/gl/GLext.h:6681:
Code: [Select]
#ifndef GL_ARB_draw_elements_base_vertex
#define GL_ARB_draw_elements_base_vertex 1
...

 

Offline Valathil

  • ...And I would have had a custom title if it wasn't for you meddling kids!
  • 29
  • Custom Title? Wizards need no Custom Title!
i think i see what is happening here. Swifty included those function prototypes because in his mac test he couldnt find the ProcPtr's in his glext headers. However he named the functions XXXXX instead of XXXXXXProcPtr like every other function prototype on mac so what happens now if your mac install has a newer glext in it it triggers the ifndef but the #defines in glextension.h look for the XXXXX format. I did a full Code Review of the go_even_faster patch as a courtesy to swifty and advised him strongly about changing the function prototypes to XXXXXXProcPtr so i guess either the next version he posts or the direct commit will have this in and should alleviate any leftover problems with the mac stuff.
┏┓╋┏┓╋╋╋╋╋╋╋╋╋┏┓
┃┃╋┃┃╋╋╋╋╋╋╋╋╋┃┃
┃┃┏┫┃┏┳━━┓┏━━┓┃┗━┳━━┳━━┳━━┓
┃┃┣┫┗┛┫┃━┫┃┏┓┃┃┏┓┃┏┓┃━━┫━━┫
┃┗┫┃┏┓┫┃━┫┃┏┓┃┃┗┛┃┗┛┣━━┣━━┃
┗━┻┻┛┗┻━━┛┗┛┗┛┗━━┻━━┻━━┻━━┛

 

Offline Echelon9

  • Moderator
  • 210
Yup, using XXXXXXXProcPtr form makes sense to me too.

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Ganbatte Swifty-sama~
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
i think i see what is happening here. Swifty included those function prototypes because in his mac test he couldnt find the ProcPtr's in his glext headers. However he named the functions XXXXX instead of XXXXXXProcPtr like every other function prototype on mac so what happens now if your mac install has a newer glext in it it triggers the ifndef but the #defines in glextension.h look for the XXXXX format. I did a full Code Review of the go_even_faster patch as a courtesy to swifty and advised him strongly about changing the function prototypes to XXXXXXProcPtr so i guess either the next version he posts or the direct commit will have this in and should alleviate any leftover problems with the mac stuff.

That's not what's happening. #define GL_ARB_draw_elements_base_vertex 1 is getting called first in glext.h so regardless, the base vertex function pointers in gropengl.h won't get set.

I'll add ProcPtr to those function pointers for posterity but what's the real solution? Should I just remove those #defines? should I throw the #ifndef into the #else subconditional?

 

Offline Valathil

  • ...And I would have had a custom title if it wasn't for you meddling kids!
  • 29
  • Custom Title? Wizards need no Custom Title!
That's not what's happening. #define GL_ARB_draw_elements_base_vertex 1 is getting called first in glext.h so regardless, the base vertex function pointers in gropengl.h won't get set.

and because #define GL_ARB_draw_elements_base_vertex 1 is getting triggered you dont have anything that defines the #PFNGLXXXXX YYYYY conversions in glextensions.h just rename those to ProcPtr also leave the other stuff where it is and it should work with both old and new glext.h
┏┓╋┏┓╋╋╋╋╋╋╋╋╋┏┓
┃┃╋┃┃╋╋╋╋╋╋╋╋╋┃┃
┃┃┏┫┃┏┳━━┓┏━━┓┃┗━┳━━┳━━┳━━┓
┃┃┣┫┗┛┫┃━┫┃┏┓┃┃┏┓┃┏┓┃━━┫━━┫
┃┗┫┃┏┓┫┃━┫┃┏┓┃┃┗┛┃┗┛┣━━┣━━┃
┗━┻┻┛┗┻━━┛┗┛┗┛┗━━┻━━┻━━┻━━┛

 

Offline Echelon9

  • Moderator
  • 210
Worked this one through with Swifty today, and the code patch to go_even_faster here, fixes the Mac compile issues.

Thanks Swifty and Valathil.

go_even_faster ready to commit?

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
It's done.