Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Studio Chat / ran out of GPU ram (screenshot included)

Author
Message
haliop_New
User Banned
Posted: 31st Mar 2019 19:29 Edited at: 31st Mar 2019 19:32
Link
never occurred to me on AppGameKit classic, am I doing something wrong? do I need to delete all the sprites before exiting the app? isn't it like java it simply deletes everything?
the crash dialog says "use smaller images"... I have 7 pngs of 512x512 each. and I load them only once. so ... what exactly ran out of memory? there are about 50 sprites on screen total.

crash dialog


images loaded

Attachments

Login to view attachments
Back to top
Profile
Bored of the Rings
User Banned
Posted: 31st Mar 2019 19:45
Link
I also got similar message, If I get it again I'll post screenshot.
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Back to top
Profile
haliop_New
User Banned
Posted: 31st Mar 2019 20:04 Edited at: 31st Mar 2019 20:04
Link
one thing I can think that may cause this is:
see those clouds?
they are created with the scene editor here is a picture


these clouds use Tweens and some kind of randomization for their size, angle, and the speed of movement (which is actually the amount of time it takes for the tween from start x to end x )
so maybe just maybe, when I resize them, rotate them, reposition they are rebuilt in memory? there for there are about 30 of them, 30x512x512 every like avg 25 seconds.... however I do have a GPU with 2GB ram.

Attachments

Login to view attachments
Back to top
Profile
GunnerJnr
AGK Developer
8
Years of Service
User Offline
Joined: 30th Nov 2015
Location: Bridgwater, UK
Posted: 31st Mar 2019 20:08 Edited at: 31st Mar 2019 20:13
Link
Perhaps you could share line 35 of your main.agc seems to be where it points to with the error, but it is generally good practice to clean up after yourself if switching from say the menu to a game level/scene etc.. I guess you can just use the SetSpriteVisible() to hide it but it will still be using the memory, Maybe you have accidentally put a draw call in the main do loop and it is just drawing it over and over ? hard to say without seeing the code? Might just be a bug in studio?? but personally, if moving to a new scene I create a clean up function, something simple like:



Please be aware there are also singular functions for this such as DeleteImage(), DeleteSprite(), DeleteText(), DeleteSound() etc.. if you don't need to delete everything but just one thing.

Thinking about it, I do remember there being some max size restriction in AppGameKit Classic, something like 2048x2048 so perhaps if you have drawn a load of 512x512 side by side and off screen it could be hogging it?



EDIT!!!

I would also recommend using some of the built in debugging tools/help (obviously AppGameKit Classic didn't have this but you could use this to your advantage in studio, get adding them variables to the watch window and step through your program, add break points at each function call perhaps?)

Also a simple function to print some info to the screen might not be a bad idea, I normally use something like this (feel free to modify and remove anything that might be redundant to you)

Personal Portfolio Website
Back to top
Profile PM Email Website
haliop_New
User Banned
Posted: 31st Mar 2019 20:26
Link
cool yeah...
however, my question was does AppGameKit studio deletes all sprites, etc at program exit.
if so, there is no real problem with my code...
I have about 50 sprites completely on the screen there is no creation or re-creation of them anywhere in the game loop.

I do have 4 sprites that are much bigger than 512x512 but still uses a 512x512 texture file. I will remove those and see what happens. so it might be a scene\agk problem
line 35 at main.agc points at Sync() inside the main loop.

and there is only one scene in the entire app first to load then loops inside it.
Back to top
Profile
haliop_New
User Banned
Posted: 31st Mar 2019 20:30 Edited at: 31st Mar 2019 20:33
Link
removed the bigger sprites but still, it crashes.

tried on FPS run also
Back to top
Profile
GunnerJnr
AGK Developer
8
Years of Service
User Offline
Joined: 30th Nov 2015
Location: Bridgwater, UK
Posted: 31st Mar 2019 20:32
Link
haliop_New wrote: "does AppGameKit studio deletes all sprites, etc at program exit"


Very good question, I cannot answer it. If it doesn't it could have a memory leak of some kind..

haliop_New wrote: "I do have 4 sprites that are much bigger than 512x512 but still uses a 512x512 texture file. I will remove those and see what happens. so it might be a scene\agk problem "


Sounds like a good idea.

EDIT!!!

haliop_New wrote: "removed the bigger sprites but still it crashes."


not good I would post as a possible bug on github
Personal Portfolio Website
Back to top
Profile PM Email Website
haliop_New
User Banned
Posted: 31st Mar 2019 20:35
Link
ok posting now.
Back to top
Profile
haliop_New
User Banned
Posted: 31st Mar 2019 20:43
Link
posted.
Back to top
Profile
haliop_New
User Banned
Posted: 31st Mar 2019 21:02
Link
removed about 25 sprites and still the same bug.
Back to top
Profile
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 31st Mar 2019 23:49
Link
Quote: "however, my question was does AppGameKit studio deletes all sprites, etc at program exit."

I'm pretty sure all memory that has been used in your program is automatically set free when ENDing your program.
So the DeleteAllSprites(), DeleteAllImages() etc commands don't need to be called before the END command.
They are only useful to free memory WHILE your code is running.

Not 100% sure about this, though. Need a dev to confirm


PSY LABS Games
Coders don't die, they just gosub without return
Back to top
Profile PM Website
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 1st Apr 2019 00:36
Link
Do you use copyimage() at all
Back to top
Profile PM
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 1st Apr 2019 01:43
Link
Are you sure your IntroSetup() is not in a loop somewhere?

Is your Intro_Loaded a global? If not, its going to start out as 0, since you're not passing it to the function.
Back to top
Profile PM
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 1st Apr 2019 02:11
Link
Intro_Loaded is a global, line 6
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Back to top
Profile PM Email Website
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 1st Apr 2019 02:15
Link
Strictly speaking in a "Worst Case" Scenario., you're only using around 210MB V-RAM (30MB S-RAM) assuming that you're using Full Precision Floating-Point (R32) Encoding.
With this said., it's difficult to speak in regards to how this is being handled via the AppGameKit Studio (Vulkan) Engine and Asset Management System.

This isn't strictly aimed at you, but rather the TGC Development Team... but one of the key issues *A LOT* of Development Studios are having when switching from Classic Graphics API (SDL, OpenGL, DirectX 11 or Below) is that Memory used by Asset Management and Generation was handled entirely internally via the Graphics API (well Graphics Drivers).
A result of this is Developers switching from HAL to CTM APIs, while they might be fairly well versed in System Memory Management have NEVER touched Video Memory Management essentially during their entire Careers., and so will typically overlook (or for performance reasons) omit typical Garbage Collection and/or be much more prone to Memory Leak Operations.

Now there's also another factor at play, being that Windows Virtualisation means you have to be sure to request what you need prior to commit.
This is why most Games will Reserve basically you're entire V-RAM., when they might only use like 1.5 - 3.0GB of it... because if they don't Windows will be like "Oh Free Memory... Om Nom Nom Nom" (especially if you have a Browser Running in the background., like YouTube or something)

…

Oh and as a quick side note., for better Memory Management (and GPU Performance) I'd strongly suggest getting the Intel DDS Tools for Photoshop CC (NVIDIA's tools are woefully out-of-date) as well as AMD's Compressonator Application.
As Compressing Images doesn't just mean that they'll use less Space., but if you use a Native Compression Format for the Target GPU, it no longer has to spend time converting to a Native Format.

PNG/TGA/TIFF is good for Development Purposes (due to being "Raw" Formats without Compression Artefacts., plus they don't take long to Calculate Save and MIPs) but for actual Production Ready., you want to switch unless you need portability (say PNG for HTML5).

And for those working with 3D., AMD's Tootle Application is great for Vertex Efficiency Ordering, Optimisation as well as Tessellation Optimisation for both Traditional and Tiled Rendering.
Back to top
Profile PM Email Website
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 1st Apr 2019 02:16
Link
Gotcha. Missed it.
Back to top
Profile PM
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 1st Apr 2019 07:57 Edited at: 1st Apr 2019 08:00
Link
I'm fairly certain Vulcan isn't in yet, it's still essentially AppGameKit classic.

So I wonder if the media caching studio itself does is an issue. If you load studio and don't run your program, what does task manager say your gpu ram commitment is?

Raven, I'm confused by your image format comments. When we load an image AppGameKit turns it into raw data in memory.....why would the format in any way impact running performance of the gpu? Isn't that literally just a space and load speed issue?
Back to top
Profile PM
haliop_New
User Banned
Posted: 1st Apr 2019 10:42 Edited at: 1st Apr 2019 10:46
Link
Hi, sorry to disappoint and happy to tell
1. the problem was in my code I got a loadImage command somewhere in the loop without noticing (in the other agc file which I connected to the scene)
2. I let the pc run for like 30 minutes with the app running, everything is fine. it is all working well.

I have re-edited my bug reporting on GitHub.
it might be wise to add a "Warning Dialog" somehow that tells that a duplicated image has been loaded again and the # number of times it occurred.
Actually thinking of it, a Warning Dialog might be a good idea before the app is going to crash since like, in this case, you know for example that multiple loading of images will crash memory, if the script handler can calculate the difference between the times the image was loaded again and again it will probably know, as learned here, the app will crash soon as all GPUs have a RAM limit.


so I guess I should go eat a shoe

sorry about this.
Back to top
Profile
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 1st Apr 2019 11:19
Link
Not at all matey. This is what the forum is for. People helping people
Back to top
Profile PM
GunnerJnr
AGK Developer
8
Years of Service
User Offline
Joined: 30th Nov 2015
Location: Bridgwater, UK
Posted: 1st Apr 2019 11:36 Edited at: 1st Apr 2019 11:36
Link
Yay! Looks like that little debug info function I posted above might of proved handy after all with number of images drawn being displayed

Glad you found it!
Personal Portfolio Website
Back to top
Profile PM Email Website
haliop_New
User Banned
Posted: 1st Apr 2019 14:54
Link
actually, it's not the number of sprites ... because none were created after startup
but a simple load image function.


ballonImg = loadImage("ballon.png")


cruising the main loop frames as it owns it.
this makes me wonder if an image is at the size of ####x#### multiple by the number of images loaded for the game, but you don't want it to consume the entire ram of your GPU lets say you want it to use max 30% of your available ram.
so you define with a command
{code]
setMaxGpuRamAvailable(getDeviceGpuRamAvailable()*0.333)


getDeviceGpuRamAvailable is set the current state of the device's ram this way you never cross a maximum barrier no matter what game you are running, to allow the user to run multiple apps at the background and to create an experience which does not consume your device and still acting right.

once you reached the barrier of the available ram, you will not be able to load any more images. so in that instance or any thinkable others, you resize your images by dividing its resolution by 2 until you have enough space to load more images.
I guess with a bit more temps and globals we can even create separate MaxRamUsage for all kinds of elements like backgrounds, tiles, characters and of course 3d, so once you have an entire project you can decide how much ram to give these elements in order to maybe achieve higher FPS in some scenarios.


Back to top
Profile
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 1st Apr 2019 15:30
Link
I'm confused......by using a variable you shouldn't get loads of images.....if anything I'd expect an error saying the image already existed?!?

So for example if you said myimage=loadimage(name), then myimage now holds that image number. If you try and load it again, should it not give an error?

I mean you got it working, so it must be it......but that's odd behaviour is not not?
Back to top
Profile PM
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 1st Apr 2019 22:56
Link
Quote: "I'm confused......by using a variable you shouldn't get loads of images.....if anything I'd expect an error saying the image already existed?!?

So for example if you said myimage=loadimage(name), then myimage now holds that image number. If you try and load it again, should it not give an error?

I mean you got it working, so it must be it......but that's odd behaviour is not not?"


That form of load image doesn't know or care what you store its return into. What you describe applies to loadimage(path, number)

Number = loadimage(path) // loads to image 1
Print(number) //1
Number = loadimage(path) // loads to image 2
Print(number) //2
Repeat until crash

Number = 1
loadimage(path, number) // loads to image 1
loadimage(path, number) // reload to image 1 overwriting the first? Reloads but leaks memory used by the first? Error image already exists?
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Back to top
Profile PM Email Website
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 2nd Apr 2019 00:02
Link
Santman wrote: "Raven, I'm confused by your image format comments. When we load an image AppGameKit turns it into raw data in memory.....why would the format in any way impact running performance of the gpu? Isn't that literally just a space and load speed issue?"


It depends on how AppGameKit itself actually handles Assets.
Just because it appears as if Assets are being loaded as a Raw Formats within Memory... that doesn't necessarily mean that's actually how they're being stored.
Of course they could be, but then that ends up offloading the task of Compression to the Driver / Hardware; resulting in additional Cycles for the Copy Operations... where-as it's more efficient to have them stored in a Native Compression Format (by-passing Driver / Hardware Compression) and instead having the Overhead on Manipulation; which keep in mind if you're handling the Manipulation via a Shader (Compute / Pixel) then, that's all occurring on the Hardware itself that's operating via the Native Compression Format; so there's no overhead... where-as doing this via the CPU, there's a bit of Overhead.

If AppGameKit was purely a Desktop Application (Linux / MacOS / Windows) then sure... this would be a reasonable approach., but for Mobile (ARM) Platforms (w/PVR or Adreno) that'd be quite an inefficient approach.
I'm not saying that's not how they do it., just not ideal.

As such... I'm assuming that they're using "Best Practises"., which means that it's using a Colour Compression Format (again remember that OpenGL 4.3, OpenGL ES 1.2, Vulkan, DirectX 10+) all utilise Native Compression by Default. Sure, you can force them into a Raw Mode... but it's not recommended.
With this being the case, then should you already be using a Compression Format Pre-Calculated .. then this tells the Graphics Pipeline / Drivers "I want to use this DCC pipeline" as opposed to them selecting a basic one typically with quite lossy results.

You're essentially by-passing a lot of work that would otherwise occur., both in the API / Drivers / Hardware. This translates to better performance., not just lower Memory Usage.
Back to top
Profile PM Email Website
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 2nd Apr 2019 08:23
Link
Ortu,

Quote: "Number = loadimage(path) // loads to image 1
Print(number) //1
Number = loadimage(path) // loads to image 2
Print(number) //2
Repeat until crash"


Ah I see......I always made the assumption that if you used the same variable name again in T1 that it would erase any content held before. That's interesting.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-19 11:01:05
Your offset time is: 2024-04-19 11:01:05