Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - iMer

Pages: [1]
1
Graphics / Re: Hang after sf::RenderTarget::clear
« on: August 16, 2014, 02:51:01 pm »
Bleh, turns out it was my drivers fault after all.
Updated from 13.something to the newest version (14) and everything works fine

Thanks for your help anyways

2
Graphics / Re: Hang after sf::RenderTarget::clear
« on: August 16, 2014, 02:27:18 pm »
It just stops doing anything/blocks and never continues

Any ideas how I can debug that?
In that case, if it really just blocks forever, you can break in the debugger and show us the full stack trace.

You need to be more specific when specifying your graphics hardware and driver version. "Seems to be up to date" isn't good enough. Many laptop users say that as well when they are using 5 year old drivers.
That's where I'm having issues.. gdb doesnt exactly cooperate for whatever reason
There definitely shouldn't be 5 threads
(click to show/hide)
A different debugger shows 4 threads with a similar stack trace
So, then I tried using Visual Studio (Man that GUI is confusing if you never use it)
Same stack trace as in the op: http://puu.sh/aUPmj/19faffb936.png not sure what to make of that (line 22 is actually the 2nd std::cout <<... guess thats just a inconsistency)

I grabbed glintercept and let that log (both the vs and mingw version stop at DXCloseDeviceNV)
(click to show/hide)

3
Graphics / Re: Hang after sf::RenderTarget::clear
« on: August 16, 2014, 01:25:53 pm »
There is no delay for me when running that code. It just runs as if nothing blocked at all. Must be something that is specific to your driver.
Well, there isnt any delay
It just stops doing anything/blocks and never continues

Any ideas how I can debug that?

4
Graphics / Re: Hang after sf::RenderTarget::clear
« on: August 16, 2014, 12:56:26 pm »
Apparently I was editing my code while you replied, see Edit2 for a minimal test case
Quote
Many beginners make the mistake of believing that they gain from splitting their graphics operations up among multiple threads

I only do the graphics from that thread since it's the only threadsafe way to render debug stuff from box2d without locking the graphics/logic thread completely, it should work though.
It's more the logic/graphics seperation I'm looking for - call it premature optimization, but I think such a drastic design element is easier to implement at the start instead of patching it in later.
I might not ever use it really, it'll be a good excercise regardless.

I also included the binary in case you cant be bothered to compile the code yourself
I cant upload an attachment (84kb):
Quote
An Error Has Occurred!
The upload folder is full. Please try a smaller file and/or contact an administrator.

5
Graphics / Re: Hang after sf::RenderTarget::clear
« on: August 16, 2014, 12:07:17 pm »
It's only blocking while it's drawing the debug graphics to the render texture, which i'll disable in production versions anyways.

Simple pseudocode
Physics:
while(running){
    simulatePhysics();
    updateEntities();
    mutex.lock();
    prepareDebugTexture();
    mutex.unlock();
}
Graphics
while(running){
    window.clear();
    m_window.draw(scene); // scene is a drawable, passes down call to children
    mutex.lock();
    m_window.draw(debugTexture); // simplified, using a sprite+getTexture
    mutex.unlock();
}
See Edit2 for a simple test case
(click to show/hide)
Edit:
Quote
and at last check if it makes a difference when disable the multi thread graphics optimization in your driver settings.
No idea how I'd do that


Edit2:
Minimal testcase code:
#include <SFML/Graphics.hpp>
#include <thread>
#include <iostream>
sf::RenderWindow window(sf::VideoMode(1024, 576), "SFML works!");

void graphics() {
    window.setActive(true);
    while(1){
        window.clear(sf::Color::Green);
        window.display();
    }
}

int main(int argc, char** argv) {
    window.setActive(false);
    sf::RenderTexture rentex;
    rentex.create(500, 500);
    std::thread d(graphics);
    while (1) {
        std::cout << "preclear" << std::endl;
        rentex.clear(sf::Color(0,0,0,0));
        std::cout << "postclear" << std::endl;
    }
    return 0;
}
 
Hangs after preclear when either window.clear or window.display is being used in the thread
gcc version 4.8.1 (rev5, Built by MinGW-W64 project) (32bit)
I've tried the "GCC 4.7 TDM (SJLJ) - 32 bits" binaries as well as self built ones with fresh sourcecode from github

6
Graphics / Hang after sf::RenderTarget::clear
« on: August 16, 2014, 09:50:04 am »
Hey,
I am having some issues with (seemingly) random hangs at startup while clearing a RenderTexture
My setup looks like this:
Main Thread does Logic/Physics at a fixed "frame"rate
Graphics thread renders as fast it can

I use box2d for physics and make use of the debug drawing, to do so I have a mutex-protected rendertexture which I render stuff to once per logic cycle and the graphics thread simply draws it.

Like I said, I have some issues that sometimes (feels like every damn time after every compile&run) the process will simply hang.
I'm working on windows under MinGW. I tried debugging the thing with gdb, but that didnt give me any useful stack traces whatsoever, so I created a memory dump of the process and loaded that up in visual studio: http://puu.sh/aUEcb/f10b5617c6.png
test.exe!40a6aa is where it calls "m_texture.clear(sf::Color(0, 0, 0, 0));"
Code: http://puu.sh/aUEec/8951a49c94.png
Assembly: http://puu.sh/aUEpZ/94ad99483e.png

sfml-graphics-d-2.dll!68ee0c65 is a call to sf::Context::setActive in bool "sf::priv::RenderTextureImplFBO::activate(sf::priv::RenderTextureImplFBO *const this, bool active)" (why does it call activate again? I already set it to active)
Assembly: http://puu.sh/aUEkH/10767d1ac6.png

After that it seems to get lost in the ati dll
I've got a  AMD Radeon HD 7800 (dont know exactly which version, can be looked up if needed though) and video drivers seem to be up to date
Does anyone have any idea what might be causing this?

Pages: [1]