Intel GPUs (again)

[slotdev]

Hi

So we're trying to get performance out of this crappy Intel 82855 chipset (64mb VRAM...so it says). We have the some strange issues, whereby the CPU goes to 100% and the game is (of course) unplayable - 1fps approximately.

Some testing has revealed that by changing the 1024x768 background into 16 tiles has fixed the problem..but it's not really a good solution.

It looks like when its trying to copy large items, it really hits this bottleneck. I guess its a fill rate problem. Its wierd as the game really isn't very complicated and nor are there many things being drawn. I hate old hardware, but we have to use it

Does anyone have any ideas for testing/debugging to try and find a good solution?

Thanks
Ed

[eXpl0it3r]

If you'd share some code we could maybe point out a few things.

[slotdev]

So basically, we have a std::map of sprite objects (gameSprites). Every render, we do this:

                        for (size_t i = 0; i < displayListLen; i++)
                        {
                                string tmpStr = displayList.at(i);
                                if (gameSprites[tmpStr].gfxScr == 1)
                                        window1.Draw(gameSprites[tmpStr].Sprite);
                        }
 

...that's pretty much it. As I said, I can trace this to the size of sprites being drawn. Lots of little sprites = no problems. One or more large sprite = 1fps. Not sure if there is anything else you need to see?

We load the tiles/images at start-up, and then display. The problem only seems to be on this hardware

[eXpl0it3r]

Oh a SFML 1.6 user and I started to believe that we've got them all converted to SFML 2 users.
But seriously SFML 2 may give you better performance since you create the textures directly on the GPU instead of copying it every draw cycle from the RAM to the GPU.
Also afaik Intel GPUs have problems with textures not being of a size two squared (8, 16, 32, 64, ...). So you could pack the wanted images into one file with a two squared size and juat change the subrect/texrect. But make sure you create sizes that are not too big for your GPU.

[slotdev]

No no, we're on SFML2 - just an older version (updating our code base is a big job - but one we have to do sooner or later).

Infact, our build is from 09/10/2011 - but I am sure that nothing that would fix this problem, has been added in more recent versions of the code.

[eXpl0it3r]

Yeah that's before the big graphics API change (I think) so your images are still kept in the RAM and not the CPU.

[slotdev]

Hmm...why then does it go wrong when I have 16 tiles making a 1024x768 image, versus 1x 1024x768 image? The CPU is copying the same amount of data, in total.....................?

[eXpl0it3r]

I'm just making suggestions.
I'm not a developer from Intel, SFML or OpenGL so I've no idea what goes wrong.

Additionally there's often a big difference if you to 16times something small or one time something big despite the amount of processed data.
E.g. you can fit small packages between the traffic without much influencing anything, but putting up one big block of data can block all traffic.

[slotdev]

I know you're not an Intel developer - you'd be far too qualified, given how crap their drivers are

Well, I'll update to the new SFML build and see what happens. It's about time we did anyway. So, before the big graphics API update, were textures really held in system RAM as opposed to being in VRAM? I mean, I can see why performance would be bad if it had to keep swapping large textures from system RAM to VRAM all the time.

If someone can actually tell me what has changed (or point me to a thread on here) I would appreciate it

[eXpl0it3r]

I know you're not an Intel developer - you'd be far too qualified, given how crap their drivers are

Hehe.

Well, I'll update to the new SFML build and see what happens. It's about time we did anyway. So, before the big graphics API update, were textures really held in system RAM as opposed to being in VRAM? I mean, I can see why performance would be bad if it had to keep swapping large textures from system RAM to VRAM all the time.

Yeah maybe I'm not that qualified, I've actually no idea where what gets store exactly, I just know that the sf::Texture is directly in the GPU and the sf::Image is held somewhere else.

If someone can actually tell me what has changed (or point me to a thread on here) I would appreciate it

Somewhere in the deep infinity there's a thread which listed some changes, but if you'd somehow find it, the list is quite uncomplete since it has never been updated. Unfortunatly there's no public changelog and I guess the best way to get uptodate is by looking at the doxygen documentation. Upfront I can tell you the two most imporant changes:

• Every function is no camelCase instead of CamelCase.
• The sf::Image got replaced with the sf::Texture except for pixel manipulation and saving to disk.

[slotdev]

Thanks for the help. With the new version of SFML, and this test code:

int _tmain(int argc,_TCHAR *argv[])
{
     // Create the main window
         sf::RenderWindow window1(sf::VideoMode(1024,768,32), "SFML window 1",sf::Style::None);
         sf::RenderWindow window2(sf::VideoMode(1024,768,32), "SFML window 2",sf::Style::None);

         sf::Vector2i pos(1024,0);
         window2.setPosition(pos);

         window1.setFramerateLimit(30); // Set to 30fps max
         window2.setFramerateLimit(30); // Set to 30fps max
 
     // Load a sprite to display
     sf::Texture texture;
         if (!texture.loadFromFile("test.png")) // could be a PNG, whatever
         return EXIT_FAILURE;
     sf::Sprite sprite(texture);

     // Start the game loop
         while (window1.isOpen())
     {
         // Process events
         sf::Event event;
                 while (window1.pollEvent(event))       // Click X in top right of window to close program
         {
             // Close window : exit
                         if (event.type == sf::Event::Closed)
                         {
                                 window1.close();
                                 window2.close();
                         }
         }
 
         // Clear screen
                 window1.clear();
                 window2.clear();
 
         // Draw the sprite - see Sprite::Render where vertexs are added, and Renderer::ProcessVertex where the gl stuff is done
                 window1.draw(sprite);
                 window2.draw(sprite);

         // Update the window
         window1.display();
         window2.display();
         }
         return EXIT_SUCCESS;
 }

I get 100% CPU. Switch to 1 window, and it's 1% CPU

Run it on other (non Intel 82855 chipset) and with 2 windows - which we need to have - it's 1% CPU again. So it is the crap hardware that's the problem, and by the looks of it, nothing can be done to fix this with the new SFML updates. Oh well!