RenderTexture not working on Intel GPUs

[sashoo]

Hello.

I found a bug that occurs on all Intel GPU systems.
Any kind of RenderTexture usage causes the program to display black screen, no matter how big your RenderTexture is.

This is the minimal code:

#include <SFML/Graphics.hpp>

int main()
{  
    sf::RenderWindow window(sf::VideoMode(800, 600, 32), "SFML bug");
    sf::Shape Polygon;
    Polygon.AddPoint(50, 50, sf::Color(255, 0, 0), sf::Color(0, 128, 128));
    Polygon.AddPoint(120, 150, sf::Color(255, 0, 0), sf::Color(0, 128, 128));
    Polygon.AddPoint(20, 200, sf::Color(255, 0, 0), sf::Color(0, 128, 128));      

    sf::RenderTexture texture;  
    texture.Create(400, 300);

    bool isPlaying = true;
    while (window.IsOpened())
    {        
        sf::Event event;
        while (window.PollEvent(event))
        {  
            if ((event.Type == sf::Event::Closed) || 
               ((event.Type == sf::Event::KeyPressed) && (event.Key.Code == sf::Keyboard::Escape)))
            {
                window.Close();
                break;
            }
        } 
        window.Clear();
        texture.Clear();

        texture.Draw(Polygon);
        texture.Display();

        sf::Sprite sprite(texture.GetTexture());        
        window.Draw(sprite);
        window.Display();
    }

    return EXIT_SUCCESS;
}

On machines with Intel GPUs this produces black screen. But on machines with other GPUs a red triangle on a black background is seen clearly.
The same problem can be also reproduced using the pong example. Just add the following line in the beginning of the program:

sf::RenderTexture texture;
texture.Create(400, 300);

Even adding these two lines (without modifying anything else) produces black screen on Intel GPU machines.

This issue makes playing games which use RenderTexture for drawing entirely impossible on afore-mentioned configurations.
I am using the latest SFML2 build, and all the machines I tested this issue on run Ubuntu 11.10

[retep998]

Most likely because Intel's gpus totally suck. Their version of OpenGL is always seriously outdated. I'd sooner use my 6 year old AMD integrated (which runs that example fine) rather than the latest and greatest intel gpu.
Anyway, easiest permanent solution here is to find alternative code to replicate the effect of a FBO (which I assume is what SFML uses). A pixel buffer or plain old software rendering is in order here.
A quick temporary fix is to simply ask GLEW if FBO's are supported, and if not then don't use them. At least provide an error message to the user about their shitty choice of gpu.

[sashoo]

At least provide an error message to the user about their shitty choice of gpu.

Some people use notebooks and laptops with integrated video cards since they usually don't need a dedicated one. Intel does have a bad reputation for making crappy integrated GPUs, but still this is not the reason to say "your choice is wrong" to a big share of users.

[Groogy]

Well technically... STRICTLY technically... their choice is wrong =)

Anyway the problem is that it's an error generated inside the drivers from intel so SFML can do nothing. I don't have a perfect vision of how SFML works internally but I guess if the render texture is not available in OpenGL SFML provides a kind of slow backup done on the CPU right? That could be used I guess in case the user has an intel GPU. Just an idea for Laurent.

So as I said, technically their choice is wrong since they bought something half-made =)
Because the problem with intel and likewise drivers is that "fix one error and a new one appear". Even if Laurent fixes this a new error with intel integrated graphics will appear somewhere. I did own a intel based laptop and I could play less than 10% of the games without any graphical artifacts. Drivers are really bad when they even are able to mess with the garbage collector of a language(as I noticed when developing rbSFML)

[sashoo]

Anyway, I think it's best if Laurent will say for sure whether this is fixable or not.
"Intel is bad" is a nice line indeed, but it doesn't clarify anything.

[retep998]

The standard OpenGL method for render textures is by using an FBO. Intel doesn't support FBO's, therefore all Laurent has to do is add alternate code for Intel using Pixel Buffers or software rendering. It's easier said than done.

[bastienleonard]

It would be interesting to know if the problem comes from the Linux driver, if someone can test on Windows...

[retep998]

@bastienleondard - I use windows myself and I've encountered this issue numerous times before, so its not platform-specific.

[sashoo]

I use windows myself and I've encountered this issue numerous times before, so its not platform-specific.

Sad to know.
Thanks everyone for your answers.

Intel doesn't support FBO's, therefore all Laurent has to do is add alternate code for Intel using Pixel Buffers or software rendering. It's easier said than done.

I guess that doesn't worth that much effort. Now I just want to know what Laurent will say about that to finally close the issue.

[LaurentGomila]

Intel doesn't support FBO's, therefore all Laurent has to do is add alternate code for Intel using Pixel Buffers or software rendering. It's easier said than done.

There is an alternative to FBO in SFML (not PBO, they are a different thing), otherwise sf::RenderTexture::IsAvailable() wouldn't have disappeared ;)
sf::RenderTexture is supposed to work on Intel GPUs, it's just that their drivers and my code don't like each other.

By the way, does commenting line 236 of Renderer.cpp solve the problem?

[sashoo]

By the way, does commenting line 236 of Renderer.cpp solve the problem?

You mean the following line?

if ((texture != myTexture) || (texture && (texture->myTexture != myTextureId)) || !myTextureIsValid)

I commented it and rebuilt the project. No change, still the black screen. And if I launch my game (after rebuilding it, of course), it hangs significantly, not even allowing to shut it down properly. Previously, it just silently displayed nothing, now there is a hang also :)
As I said, I am using Ubuntu Linux 11.10

Laurent, is there any chance of this issue to be solved?

[LaurentGomila]

I don't know. I'll work on RenderTexture to make it more robust, but if this is purely a driver issue... I don't know if I can help.

[Legacyx]

I'd just like to say that Intels newest drivers no long have this problem. so its no longer a bug :)

[sashoo]

Good news indeed! I will try updating the driver on my GNU/Linux machine which has Intel graphic card to see it with my own eyes.

I am sorry for pointing out that this was an SFML bug, because it seems, as expected, that Intel is the one to blame. Yet this issue has shown that not every graphic card will handle everything as smooth as the developer planned. Hopefully, now there is one problem less.

I'll post here once I run the test once again, with drivers updated and the newest SFML.

[LaurentGomila]

I'd just like to say that Intels newest drivers no long have this problem

Can you please tell us which drivers (version, OS)? I don't think that it's fixed on all drivers ;)

[Legacyx]

my details.
os: Windows 7 Professional 64-bit
driver: Mobile Intel(R) 4 Series Express Chipset Family
version: 8.15.10.2555

[simpletools]

I will be testing this myself within a few days/weeks, but I noticed there is a newer driver on the intel site.
http://intellinuxgraphics.org/2011Q4.html

I have seen conflicting information about the intel gma's support of FBO's.

[krofna]

Little update on this issue;
It seems sf::RenderTexture can be hacked to work on all GPUs. For some weird reason, if you copy texture from sf::RenderTexture into sf::Texture, destroy the sf::RenderTexture object and then draw that Texture on window, it will work.

So i suppose... Window.Draw(sf::Sprite(sf::Texture(RendText.GetTexture())); will work? (havent tested this yet)

[MarcusVoelker]

On our project, we have 3 people with Intel GPUs and using newest drivers. (2x Gentoo, 1x Arch Linux).
None of them can run the game, all crash with an intel_do_flush_lock error.

We tried nailing it down. It seems, only creating a RenderTexture and using its create function is sufficient to induce the crash.

[LaurentGomila]

Someone found that using power-of-two dimensions for the RenderTexture solved his problems.

[veywrn]

Just like to chip in that I'm running on an Ubuntu 12.04 box with an Intel GPU using kernel driver i915 and I'm having the same crash to terminal with intel_do_flush_lock error the second I try to call RenderTexture's create. Doesn't work no matter what width or height I use.

[LaurentGomila]

Solved.

More details here:
http://en.sfml-dev.org/forums/index.php?topic=9149.0