Welcome to Fractal Forums

Hey,

I am trying to run fragmentarium on Win 7 Professional and R9 280X.
The GPU is properly installed and functional. Fra reports:
This video card supports: OpenGL1.1, OpenGL1.2, OpenGL1.3, OpenGL1.4, OpenGL1.5, OpenGL2.0, OpenGL2.1, OpenGL3.0, OpenGL3.2, OpenGL3.3, OpenGL4.0, OpenGL4.1, OpenGL4.2, OpenGL4.3
The problem is that it runs extremely slow on this machine.
I tried reinstalling GPU drivers several times. No luck.

Version 1.0.6 is the last one I tested that runs on normal speed.
All later versions are extremely laggy.

Any ideas on what could be wrong?

are you running the nVidia version (exe name ends with nV) or the generic version?
have you used the Mac version ? 1.0.7, does it have the same problem?
if you can see your screen ie: no garbage all crispy clean desktop, it is not likely to be the gfx drivers, unless they have to emulate some GL hardware functions with software.

if your Win 7 is up to date with all of the latest dlls etc it may be an issue with the Qt5.3.2 dlls that I compile against, to debug this is extremely difficult for me because I don't have the same hardware, all I can do is guess at what might be going on.

brace yourself, I'm going to give you a shove... to get the best exe for your machine you should compile it on your machine that way it will be linked against all of the dlls that are specific to your machine, this is exactly why I don't like to provide precompiled executables, I can't account for all variations. The Qt SDK for windows will install everything you need (except OpenEXR) to compile the program including MinGW with gcc compiler and QtCreator IDE. This will get you started on C++ :D

edit: with nothing loaded (only default bulb frag) select menu item Edit->Preferences, set OpenGL refresh rate to 0 select Ok then select Animation and Play (>). Now observe the frame rate in the bottom right status bar.
When I do this I see 419.1 FPS
it seems to run fine here  :hmh:

It's an AMD card and I'm running generic version.
Nv doesn't make it better.

On the same machine when I boot OS X 1.0.7 works smoothly.
But I can't run OS X version as my frags won't compile at all.

The problem is visible only on win 7.
The gui starts no complaints. Bulb loads.
The frame rate I am getting is somewhat around 1 subframe in about 1-2 seconds.

Latest vis c++ redist installed, dx11.
What else I can try?

install QtSDK and recompile...

Try downloading Process Explorer from here: https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Then run Fragmentarium, and select its process in Process Explorer.

Then choose "View | Lower Pane View | DLL's" and go through the DLL's and find the OpenGL library it is linking against: it should something about OpenGL in its description, and post the result here.

I imagine the behaviour you are seeing could be due to running on the integrated GPU, instead of the discrete one.

You can also try clicking the Fragmentarium process, and go to the GPU tab, and see whether the GPU usage is maxed out, while doing animations.

Thanks, will check this out. It looks like it is not maxed out as far as I remember.
I'll be able to check it in details on Friday at earliest.

@Syntopia TY, sometimes I wish I had time to immerse myself in windows and mac OSs, I might have more constructive input if I could. I didn't consider the integrated GPU  :tongue1:
I think I squished a bug re:textures, in both my version and github Fragmentarium-master with 2 tabs open, one frag using textures the other not, after switching between tabs and using the build button, the screen goes black and the textures get lost, the same when switching files in a Sampler2D widget. The latest tweek (150812) fixes this so that cached textures are stable when switching between tabs and files. I think this might be a Qt5 thing. Can anyone confirm this?
As usual, needs testing.

I have looked into "laggyness" and found that with very complex frags github-master version is a bit slower when animating, 3.4 fps vs 4.1 fps in v1.0.10 and the gui is a bit slushy when resizing docks in both versions depending on how complex the frag is, but I haven't seen rates as low as you have Patryk :hmh: a win friend tells me that the card manufacturers driver may have to be reinstalled after win does an update, apparently MS messes with some GL stuff that may be card specific. I have also looked at 1.0.7 vs 1.0.9 and nothing seems to be an obvious cause.  sorry  :sad1:  that's all I've got.

Dick, on a PC The problem was between 1.06 which was fine and all later which are slow. I'll install win updates then reinstall drivers again then check syntopias suggestions.

Also, on another machine I still have this problem with only 1 gpu (r9280x) out of 2 being used.
When they are separate 2nd gpu is idle. When they work in crossfire sli mode, they are together slower than a single gpu.

Syntopia - you got any ideas?

just did some tests against 1.0.6 and found that it lags the same as all other versions (including github-master) when a complicated frag is loaded
uhm... could it be that your additions and changes to the raytracer and loaded frags is more complex now than when you first used 1.0.6?

I was running the test on the default settings of mandelbulb.
It's not about a minor performance drop. It's a drastic underperformance on simplest things.

First try to figure out whether your slow-down is due to changes in Fragmentarium, or in your system setup. What happens if you install the older 1.06 Fragmentarium version? Does it run at expected speeds?

Yes, As I said, on a given machine 1.06 runs full performance, any later versions are terribly slow.

Which builds are you testing against? I tried 3dickulus 1.0.9 windows build (w. MinGW dll's) from his website. and it worked fine on my machine.

If your v1.0.6 runs at full speed, there are a couple of explanation I can think of:
1) Windows use special settings for that particular exe location (such as running on integrated GPU) - did you check that with Process Explorer?
2) The .exe build is the cause
3) The shaders is the cause

Try replace the v1.0.6 exe with the newer exe. Try replacing the v1.0.6 GLSL shaders with the newer ones.

No clue what's going on here.
- I am using both 1.0.6 and 1.0.9 off the same folder with DLLs etc.
- I tried running 1.0.9 with the complete contents downloaded from Dick's website - no difference.
- Both tested fragmentariums are running exactly the same test example (default mandelbulber with DE raytracer)
- Both fragmentariums are using exactly same set of DLLs except from 1.09 using extra items QT5Script.dll
- Both fragmentariums seem to be able to saturate my R9280X GPU up to 90-100%. No other GPUs on the machine.
- 1.06 does few hundreds subframes per second, 1.09 does 1 subframe per second (same res).

I guess I'll just drop this machine and move the GPU to some other PC.

Here's the process details
https://www.flickr.com/photos/patryk-kizny/20601453476/in/dateposted-public/

I have tested against all versions and they seem fine.

Check menu Edit->Preferences

if a frag crashed and set Auto Run to false you may be trying to execute an improperly initialized shader

these are my settings..

v1.0.10 win executables (http://www.digilanti.org/fragmentarium/) are available at my website but w/o OpenEXR :sad1: because it's bedtime and the weekend is over :'(
if anyone wants EXR they will have to compile on linux or wait until someone that knows win-dev better than I can provide a solution. :-\

Patryk Kizny

the 3d card is a ATI/AMD one right

the nvidia driver will not work

now unless Microsoft has changed it's strips ( not likely )
the drivers that MS installs from "auto updates"  tend to be OpenGL disabled or crippled

Auto update will AUTO REPLACE the one you manually installed from the AMD web site

grab the amd driver from the amd site

http://support.amd.com/en-us/download

just like for Nvidia cards you use the nvidia site

@JohnVV thanks for the input, I think I said something similar... somewhere ;)
@Patryk v1.0.10 is ok? I have the internal textures follow the buffer format for consistency and so that saving EXR reads from float texture instead of int, this is relatively fast for GPU hardware to handle but if emulated on CPU I think one would see lagging to the extent that you have described.
@Syntopia I note in the DisplayWidget.cpp that there are some issues with texture mip-maps and it is disabled... I think I fixed it but not sure how to test definitively to know that it is actually working right. (not in executables yet source only)

in a frag this should create a mipmapped texture...

edit: i did find this (google) "glGenerateMipmap doesn't work on ATI as of 2011"
        and this https://www.opengl.org/wiki/Floating_point_and_mipmapping_and_filtering

Guys, thanks for your input.
I've tried a bunch of drivers (i.e. different versions coming obviously from the manufacturer).
It did not work before windows updates and it does not work either after updating.

does the github-master version exhibit the same condition? if so maybe you cooked your GPU? My GTX8800 had a meltdown from using Fragmentarium, literally.

Dick, the same thing happens on 2 separate GPUS, so I don't think i burnt it down.

I'm not sure I follow the reasoning here: If 1.0.6 still works on the same hardware, this must be a pure software/configuration problem, right?

Does this slowdown only happen when doing hi-resolution renders, or is there also a slowdown when doing ordinary interactive renders? (e.g. try setting Fragmentarium in Animation mode, and look at the FPS in the lower-right corner).

I have no idea what's happening.
No, the performance is impaired when I open a fresh fragmentarium with the default Mandelbulb frag and its setting in the screen buffer. Did not even try hires renders as clearly there is something wrong.

Is there any guide to compiling for dummies? I mean on Windows.

Well, if you installed Qt5 dev pkg you should be able to open the Fragmentarium.pro file (right click -> open with...) QtCreator, <configure> project then <build>
However, you will find that it is only that easy if everything is in place, like the current source code, v1.0.10, will probably not compile until the OpenEXR libs and headers are compiled and installed unless you #ifdef or comment out the EXR stuff. I haven't figured that out yet, hopefully the community will offer some assistance so everybody can play with the EXR version.

I found this video, CG, very nicely done https://vimeo.com/channels/staffpicks/136114837 this encourages me to help artists by providing FREE tools, vicarious artistic creativity.

to compile without EXR you will have to comment out the line
in the file Fragmentarium.pro

I also have not done any extensive testing of mip-map textures with HDR/EXR, only to the extent that the files seem to load and display properly.

did you resolve the GPU issue? drivers? hardware? windows? if not, then compiling from source may not help :(

I have experienced an extreme slow down when I left something uninitialized or not allocated properly but when that situation shows up I fix it before publishing, at least on my linux box. I took some (a lot) time to compare 1.0.6 with 1.0.9/10 sources and nothing jumps out at me as being a cause. I use the github master version as a base to compare my changes against, ie if it still runs as fast or faster I'm happy with it.

here is a shot of v1.0.10 mip-mapped hdr texture in a very simple test, using a frag posted here in the forum somewhere, just one texture on a plane. (note the frame rate bottom right)
there may be some issues with GL versions < 3.0 , but again I reiterate, this needs testing and verification. It should work down to 2.0  :-\

I have posted v1.0.10 win exes on my website but without EXR, HDR loading still works, but no EXR load/save

Just summarizing:
- I did not test the mipmaps thing on the wicked machine yet.
- 1.10 is still laggy on the wicked one.
- 1.10 runs smoothly on other machines (the build from you).