Author Topic: updated code for getting system memory  (Read 5983 times)

0 Members and 1 Guest are viewing this topic.

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
updated code for getting system memory
« on: December 12, 2019, 02:57:03 AM »
little tidbit for systems like mine with more than 4gb of system memory.

in win_shared.cpp put this at the top ->

Code: [Select]
/* functions for the below */
typedef BOOL( WINAPI *PGetPhysicallyInstalledSystemMemory )( PULONGLONG TotalMemoryInKilobytes );
#define GPA( module, func ) ( PGetPhysicallyInstalledSystemMemory ) GetProcAddress( GetModuleHandle( module ), func )

 /*
 ================
 Sys_GetSystemMemory

 description:
 retrieves installed physical memory from bios
 ================
 */
static uint64_t Sys_GetSystemMemory( void )
{
/* This code only works on XP or older */
#if ( _WIN32_WINNT <= 0x501 )
MEMORYSTATUSEX statex;
statex.dwLength = sizeof( statex );
GlobalMemoryStatusEx( &statex );
uint64_t mem = static_cast<uint64_t>( statex.ullTotalPhys ) / 1024.0; /* else it would return bytes */
return mem;
#else
/* this works on vista and up */
ULONGLONG mem; /* physical memory installed (kb) */

PGetPhysicallyInstalledSystemMemory pFGetPhysicallyInstalledSystemMemory = GPA("kernel32.dll", "GetPhysicallyInstalledSystemMemory");

/* Uh oh... */
if ( !pFGetPhysicallyInstalledSystemMemory || !pFGetPhysicallyInstalledSystemMemory( &mem ) )
{
return 0;
}

/* Couldnt get system ram */
if ( !mem )
{
return 0;
}
return static_cast<uint64_t>( mem );
#endif
}

and replace Sys_GetSystemRam with this ->

Code: [Select]
uint64_t Sys_GetSystemRam( void )
{
    uint64_t physRam = Sys_GetSystemMemory() / 1024.0;
    physRam = ( physRam + 8 ) & ~15;
    return physRam;
}

remember to change it in the header as well since the original used int as a return value.

code will now correctly report your system ram on newer windows versions, the old code could only report 4 GB max.

and get rid of the video ram detection code it no longer works correctly and also suffers from the same limit,
you can only get videoram on modern gfx cards by using card specific codepaths like this ->

Code: [Select]
void idVertexCache::Show( void )
{
GLint  mem[4];

if ( GLEW_NVX_gpu_memory_info && ( glConfig.vendor == glvNVIDIA ) )
{
common->Printf( "\nNvidia specific memory info:\n" );
common->Printf( "\n" );
glGetIntegerv( GL_GPU_MEMORY_INFO_DEDICATED_VIDMEM_NVX , mem );
common->Printf( "dedicated video memory %i MB\n", mem[0] >> 10 );
glGetIntegerv( GL_GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX , mem );
common->Printf( "total available memory %i MB\n", mem[0] >> 10 );
glGetIntegerv( GL_GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX , mem );
common->Printf( "currently unused GPU memory %i MB\n", mem[0] >> 10 );
glGetIntegerv( GL_GPU_MEMORY_INFO_EVICTION_COUNT_NVX , mem );
common->Printf( "count of total evictions seen by system %i MB\n", mem[0] >> 10 );
glGetIntegerv( GL_GPU_MEMORY_INFO_EVICTED_MEMORY_NVX , mem );
common->Printf( "total video memory evicted %i MB\n", mem[0] >> 10 );
}
else if ( GLEW_ATI_meminfo && ( glConfig.vendor == glvAMD ) )
{
common->Printf( "\nATI/AMD specific memory info:\n" );
common->Printf( "\n" );
glGetIntegerv( GL_VBO_FREE_MEMORY_ATI, mem );
common->Printf( "VBO: total memory free in the pool %i MB\n", mem[0] >> 10 );
common->Printf( "VBO: largest available free block in the pool %i MB\n", mem[1] >> 10 );
common->Printf( "VBO: total auxiliary memory free %i MB\n", mem[2] >> 10 );
common->Printf( "VBO: largest auxiliary free block %i MB\n", mem[3] >> 10 );
glGetIntegerv( GL_TEXTURE_FREE_MEMORY_ATI, mem );
common->Printf( "Texture: total memory free in the pool %i MB\n", mem[0] >> 10 );
common->Printf( "Texture: largest available free block in the pool %i MB\n", mem[1] >> 10 );
common->Printf( "Texture: total auxiliary memory free %i MB\n", mem[2] >> 10 );
common->Printf( "Texture: largest auxiliary free block %i MB\n", mem[3] >> 10 );
glGetIntegerv( GL_RENDERBUFFER_FREE_MEMORY_ATI, mem );
common->Printf( "RenderBuffer: total memory free in the pool %i MB\n", mem[0] >> 10 );
common->Printf( "RenderBuffer: largest available free block in the pool %i MB\n", mem[1] >> 10 );
common->Printf( "RenderBuffer: total auxiliary memory free %i MB\n", mem[2] >> 10 );
common->Printf( "RenderBuffer: largest auxiliary free block %i MB\n", mem[3] >> 10 );
}
else
{
common->Printf( "MemInfo not availabled for your video card or driver!\n" );
}
}

and sadly this only works on nvidia and AMD.

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #1 on: December 12, 2019, 09:10:29 AM »
A barebones (no editors) engine using the above and some fixes from darkmod like AVX optimizations and fps untangling (com_fixedtic)
as well as a hybrid GLSL and ARB2 renderer is avaliable if anyone wants to try it.

It runs smooth as butter on my AMD card  :))

thread code also had a few fixes as well as the VBO cache.

If someone wants to try toying with depth access, set r_skipDepthCapture to 0 and provide a shader (darkmod has a working one),
you will need to add it to progDef_t in draw_interactions.cpp the support code is allready there but you would need to supply code for using the depth access (like soft particles SSAO etc).
The support code will get yor cards depthbuffer capabilities and set the depth access bits automatically (most cards today can do 24 bit depth anyway, but in case it cannot and the driver reports it correctly, it will autoset the bitdepth to whatever your card supports).

I have a github site where i will upload the code, still toying with openal soft and adding framebuffers.

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #2 on: December 17, 2019, 04:34:38 PM »
Well this is wonderfull, github destroyed my project by overwriting all my changes with the old code despite being told not to  >:(

SO this project will go no further and im done with git.

caedes

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +19/-11
  • Demon Herder
    • View Profile
    • My Github Account
Re: updated code for getting system memory
« Reply #3 on: December 18, 2019, 06:46:31 AM »
did you try to restore the old (or rather latest unbroken) state locally with git reflog?

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #4 on: December 25, 2019, 08:25:07 PM »
tried everything the error is not recoverable as it decided the next push that my local copy was not in sync with the online one,
so it merged my local copy with the broken online commit and thats all she wrote.

caedes

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +19/-11
  • Demon Herder
    • View Profile
    • My Github Account
Re: updated code for getting system memory
« Reply #5 on: January 06, 2020, 04:49:23 PM »
Do you still have that git repo on your harddisk?
It might still be possible to get the last (committed) state before it merged in garbage.
(If you had uncommitted changes when the merge happened those might indeed be gone, but everything that was locally committed might be salvageable)
« Last Edit: January 06, 2020, 04:53:17 PM by caedes »

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #6 on: January 10, 2020, 05:43:57 AM »
deleted both the repo and the sources im afraid.

To many changes to the source in comparison with the old one to recreate the missing parts, i might as well have started from scratch  :-[

caedes

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +19/-11
  • Demon Herder
    • View Profile
    • My Github Account
Re: updated code for getting system memory
« Reply #7 on: January 10, 2020, 09:19:28 PM »
That's a pity :-(

From what you posted here and in comments on github you had some awesome changes, some of which I would have loved to integrate in dhewm3 like SMP multithreading changes and microsecond timing which could (or even did?) help with support for high refreshrates..

Well, shit happens, I guess :-/

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #8 on: January 14, 2020, 09:44:10 AM »
darkmods smp changes are easy to get at, they are all commented in the idlib math source code.
There is however one snag since they removed old MMX and ALTIVEC paths there are a few places with commented code for that which needs to be reactivated.

The timing code makes use of some std:: functions which may not be in all versions of MSVC so be carefull there.

The multithreading code however was lost which indeed sucks  :-\  and also unfortunatly the hybrid GLSL backend.

The smp and timing changes are probably the ones you would be most interrested in, since they provide the biggest noticable performance boost.

The AVX and AVX2 smp functions are used for stencil shadow volumes, which have allways been a major ressource hog, so the boost is quite welcome there.

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #9 on: January 16, 2020, 01:56:41 AM »
i added AVX and AVX2 to the dhewm code, but you need to revisit the SDL2 libraries provided since it does not support AVX2 and it should (it has been availiable since version 2.0.4 but this version of 2.0.4 does not support it).
The timing changes will be added later because of differences in the code related to SDL which im not used to working with.

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #10 on: January 16, 2020, 06:15:57 AM »
added the base code for the darkmod SMP changes to dhewm, still a lot of work needed but its closer now.
Lots of stuff from darkmod runs through here so its easy to make mistakes and add stuff that does not belong there (lightgems framebuffers ad nauseum etc and so forth).
Since dhewm relies on SDL threads im not even certain if i can do it, main async thread runs at a different ticrate than normal 3 vs 60.

caedes

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +19/-11
  • Demon Herder
    • View Profile
    • My Github Account
Re: updated code for getting system memory
« Reply #11 on: January 18, 2020, 06:34:42 PM »
Thanks for porting those changes to dhewm3, that's awesome!

If you need help with the dhewm3 codebase or SDL feel free to ask :)

caedes

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +19/-11
  • Demon Herder
    • View Profile
    • My Github Account
Re: updated code for getting system memory
« Reply #12 on: January 20, 2020, 11:01:46 PM »
oh yeah, regarding the SMP stuff, I haven't looked at TDM but if they're using the same interface as D3BFG the following code I wrote ages ago might be helpful:
https://github.com/DanielGibson/DOOM-3-BFG/commit/edfa0ded31cb6cab76eb3eb2db27cbecf62e8d55

revelator

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +5/-0
  • Doom Newbie
    • View Profile
Re: updated code for getting system memory
« Reply #13 on: January 21, 2020, 05:01:38 AM »
thanks ill have a look at it  ;)
The simd changes needed a lot more headers in the math sources than what was originally in darkmod since those where pulled from precompiled.h originally.
the SMP changes need some std functions that i cannot guarantee will exist in all versions of msvc or even gcc so i will need to be carefull there.

caedes

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +19/-11
  • Demon Herder
    • View Profile
    • My Github Account
Re: updated code for getting system memory
« Reply #14 on: January 21, 2020, 06:57:03 PM »
Maybe we can replace the std:: stuff used for SMP with SDL functions or OS-specific functions eventually for better portability (and because right now dhewm3 doesn't use anything from std:: ), but don't worry about it for now, once we have something that works well, iterating on it should be easy(er) :)

(Also, I might be able to do the std:: replacements myself even in the limited time I currently have for dhewm3)
« Last Edit: January 22, 2020, 01:15:17 PM by caedes »