Hi,

I noticed in the last few days that my computer has been turning itself off like it has been overheating. So I stripped it down cleaned it, and tried to find the problem (E6850cpu, 620GT gpu 16gb ram Xubuntu 14.04).

What I found is that after an update (I have been unable to find which one) unless I now turn off the vsync in my allegro programme, it will run one of the cores at maximum, and overheat both the CPU and GPU till it automatically shuts off the machine. Turning the vsync off in the al_set_display_options reduces the CPU usage down to around 20%.
So I decided to check the nvidia graphic drivers as I am currently using the 331.xx ones. Using the 304.xx or 340.xx drivers will both cause the same problem, causing both cpu and gpu to overheat, regardless whether the Allegro flag for the vsync is on or off.
Disabling the vsync and flipping in the Nvidia control panel seems to reduce the cpu usage to around 15%.
I would like to try the Nouveau drivers, but they just totally mess up my monitors (I am using a dual screen configuration), which renders working almost impossible.

It seems to me like a fairly serious issue, although I suspect it has more to do with Nvidia than Allegro.
Any suggestions?

It is strange, as it seems it is when I am doing nothing that the cpu suddenly starts to increase its usage, jumping from 20% to around 50% after 30 seconds when running the Allegro program. When I shut down the program everything returns to normal which makes me think there is something very odd going on with Allegro.

nVidia had a huge driver controversy when Starcraft 2 came out where the GPU would go wide open and overheat and crash/reboot/damage-the-videocard.

http://www.dailytech.com/Hot+Starcraft+II+is+Frying+Graphics+Cards+Blizzard+Issues+Temporary+Fix/article19224.htm

Now granted, that issue should have been fixed by now. But it's certainly proof that this can happen.

I know that doesn't solve the issue, but it's a little related background info. But yeah, what Thomas said. Try and replicate the issue with the smallest piece of code you can. If you can go through the Allegro examples and one does it, then you're work is already done and just tell us which example.

ALSO, I almost forgot. Try playing around with the nVidia side VSYNC settings. They allow it in Windows, they should in Linux. Try force off, force on, and "application specific (default)". See if those change anything.

Also, make sure you mention ANY custom configuration settings in the nVidia 3-D game enhancements section where you force AA/Antroscopic Filtering/etc.

Lastly, are there ANY games now that this has happened, that it also effects outside of Allegro.

I don't know if this will solve your problem, but give it a shot as it may narrow things down.

Try, instead of

  al_set_target_bitmap(al_get_backbuffer(display));

do

ALLEGRO_DISPLAY *backbuffer = al_get_backbuffer(display); //outside of render button, in your main loop

void render_button(,,,blah blah blah,,,backbuffer) //pass it forward with dependency injection
{
//...
  al_set_target_bitmap(backbuffer); //use the pointer, instead of getting it from a call (see following note)
//...
}

Perhaps it's that al_get_backbuffer every time you render a single object that's blowing up. You should only need to get the backbuffer once per frame. I don't know if that ends up being a complex system call or a simple pass-the-pointer. But if it's a complex call that could contribute to your problem.

[edit]

Looks like I misread your code. You're saying it's not the backbuffer set_target, but it's the new bitmap one.

void render_button(int x, int y, int xsize, int ysize, ALLEGRO_BITMAP* backimage, char text[255], ALLEGRO_FONT* text_font, int distance)
{
    ALLEGRO_BITMAP *temp_button=al_create_bitmap(xsize,ysize);

    al_set_target_bitmap(temp_button);  //<- this is the problem call

    //al_clear_to_color(al_map_rgba(0,0,0,0));
    //if (backimage)      //al_draw_scaled_bitmap(backimage,0,0,al_get_bitmap_width(backimage),al_get_bitmap_height(backimage),0,0,xsize,ysize,0);
    //if (strlen(text)>0) outline_text(text_font,al_map_rgba(255,255,255,255),xsize/2,ysize/2-(al_get_font_line_height(text_font)/2),ALLEGRO_ALIGN_CENTER,text,distance);
    al_set_target_bitmap(al_get_backbuffer(display));
    //al_draw_bitmap(temp_button,x,y,0);
    al_destroy_bitmap(temp_button);
}

This is what classes and structs were made for. Then you don't need to pass in all your parameters, you simply pass a pointer to an object. You don't want to create the bitmap every time you draw it, you want to create it once and then draw it when you need to. And al_set_target_bitmap can be a very expensive call as it changes the texture that is bound.

All software, and especially all software development is capable of damaging hardware. It's just so rare that we take it for granted. It used to be as simple as setting the wrong VGA registers to damage a videocard or monitor.

And the "overheating GPU" thing isn't really Allegro's fault, even if it causes it. If in 2015, a GeForce allows itself to overheat to the point of damaging itself, then that's clearly nVidia's fault, like the Starcraft 2 fiasco. It's not like you're doing a low-level firmware update in a hard drive (which could fail if you mess it up). You're calling elaborate APIs, not registers anymore.

CPU spikes on vsync tells me they are attempting to implement vsync with a busy loop or some other such nonsense.

Okay I had the problem again, and it was the al_set_bitmap_target call at fault again inside a different function. It seems anywhere that calling al_set_bitmap_target repeatedly (as in say a ALLEGRO_EVENT_TIMER) causes the cpu to heat up to unacceptable levels.
I can work around the problem, but I am still at a loss why this would happen. Anyway I should have some time tomorrow to see if I can delve deeper into what is going on, but I am not too hopeful.

Are you changing the target repeatedly? Is there a reason you're calling that function a lot? It normally shouldn't be required.

I think we could potentially make it so allegro doesn't do any changes if it's called and the current target hasn't changed. Not sure how simple that'll be (depends on how the target stuff is handled...)

Creating new video bitmaps, and especially drawing to them can be slower than you may be expecting. It really is better to structure things such that that isn't required. Maybe try and set up a resource manager so you can just ask that manager code for a bitmap, and it'll load it if and when it's needed (and can free things that haven't been used "recently").

What do you mean by a separate image for each card?

Ah. Kind of thought thats what you meant, but had to make sure.

Shouldn't be much different than in C++. "Cleanest" way would be to use a struct and some prefixed functions that take that struct.

ResManager *rm_create(...);
ALLEGRO_BITMAP *rm_get_bitmap(ResManager *, const char *image);

the manager can cache the bitmaps in the ResManager struct, so they don't have to be reloaded all the time.

Can also stash all of the images in a texture atlas so you aren't changing textures all the time, and the returned bitmap is just a sub bitmap.

Instead of passing the res manager to each manager call, you can store the resource manager struct in a static var in the resource manager file, but just make sure to provide a rm_init and rm_deinit type set of functions so the manager can set its stuff up. I don't consider that quite as "clean" as passing around the manager var, but sometimes it gets too complicated to pass in the rm var everywhere.

Modern hardware accelerated graphics don't mesh well with how you needed to do stuff with Allegro 4. Most times with Allegro 5 its best just to draw everything every frame, which is something you had to avoid in Allegro 4.

Maybe? But in the end, what is happening is that you are loading a new bitmap, then uploading that to the GPU every single time. Uploading to and downloading from the GPU is a fairly expensive process^[1] as it requires transfers over the PCIe bus.

I find it makes it so there is less spaghetti. you get a nice layered set of subsystems that each do one basic thing, instead of a ball of code in your main game function that does everything.

Hey now, it is more than possible to create clean and readable code in C and Pascal. Now old school Basic? not so much