Cell preloading

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
Lagahan
Posts: 47
Joined: 16 Aug 2014, 11:24
Location: Ireland

Re: Cell preloading

Post by Lagahan » 13 Feb 2016, 19:42

Threw another 2 videos up comparing vanilla and OpenMW. The NVME SSD brute forces both and they end up fairly similar but when I tested it on a HDD OpenMW pulls ahead on interior load times.
SSD:
https://youtu.be/ujfksMA9HrE
HDD:
https://youtu.be/a5IYDxRrYOg
Specs: Core i7 8700k @5GHz, EVGA GTX2080ti XC SLI,
32GB RAM @3.2GHz, Windows 10 1803

User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Cell preloading

Post by scrawl » 13 Feb 2016, 20:38

Nice! For the record, the OpenMW build you have is from when the preloading feature wasn't completed yet, the latest master should be a bit smoother.
Also, to get an accurate result you should reboot in between tests, to make sure that the files are not cached by the operating system yet.

User avatar
psi29a
Posts: 4915
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Cell preloading

Post by psi29a » 14 Feb 2016, 10:21

Zini wrote:This is just a vague guess.

Maybe the compiler (or even just the error checking tool that produces this error message) does not see the function prototype of xine_xmalloc_aligned. This would then implicitly assumed to have a return type of int.

That doesn't match exactly the error description, but it would certainly not be the first misleading error message in the C and C++ space.

Does adding the line
void *xine_xmalloc_aligned(size_t alignment, size_t size, void **base) XINE_PROTECTED;
before the definition of the rgbout_update_frame_format function change anything?
Your guess was on the money! Launchpad is uploading it now. The i386 was no problem but the amd64 build was the one triggering the error. It claims that it would automatically fail on ia64 arch... which well, is a dying architecture anyone. I'm glad this worked.

Any way that this could be sneaked in upstream? For now, I'll carry the patch and hopefully get it included in Debian for now.

Cheers!

User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Cell preloading

Post by Zini » 14 Feb 2016, 12:04

Weird. This isn't building for me.
*** No rule to make target `/usr/lib/libosg.so', needed by `openmw'. Stop.
Either it is too early in the morning and I missed something obvious or something is wrong here (and yes, I did a full rebuild).

Any way that this could be sneaked in upstream? For now, I'll carry the patch and hopefully get it included in Debian for now.
This is only a workaround. Not sure if it would be appropriate to push it upstreams. The problem is either some idosyncracy of the xine build system that I didn't notice or a false positive in the detection tool.

Edit: It seems the so files are installed to /usr/lib/86_64-linux-gnu. Since the build script expects to find them in /usr/lib this can not work.

corristo
Posts: 495
Joined: 12 Aug 2011, 08:29

Re: Cell preloading

Post by corristo » 14 Feb 2016, 12:59

Mac build with cell preloading & fixed physics framerate:

https://dl.dropboxusercontent.com/u/284 ... cs-fix.dmg

User avatar
psi29a
Posts: 4915
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Cell preloading

Post by psi29a » 14 Feb 2016, 14:59

@scrawl & zini: osg 3.4 is now on the PPA, I rebuilt openmw and it seems to work like a charm. Going to do more tests later. This means that OSG 3.4 will be used on travis-ci now.

Thank you again for your help. :)

User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Cell preloading

Post by Zini » 14 Feb 2016, 15:01

As mentioned above your package does not work for me. Completely breaks the build.

User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Cell preloading

Post by scrawl » 14 Feb 2016, 15:13

@zini: I often see "No rule to make target..." errors when the cmake configuration is stale. You said that you did a full rebuild, but what does that mean? Run make clean? Try to erase CMakeCache.txt and CMakeFiles/ as well, if you haven't.

If that didn't work, have a look for openscenegraph-osg.pc files on your system, there might be some leftovers of osg 3.2 still around.

As a temporary measure, you can always install osg locally and use CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH & CMAKE_LIBRARY_PATH to point openmw to it (I actually do this all the time since I often test changes to osg).

@psi29a: nice, I've hit rebuild on travis to see if the PR builds now.

User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Cell preloading

Post by scrawl » 14 Feb 2016, 15:19

This means that OSG 3.4 will be used on travis-ci now.
It looks like there was an upload for Xenial and Wily, but none for Trusty, which travis-ci uses.

User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Cell preloading

Post by Zini » 14 Feb 2016, 15:47

Cleaning out the old CMake files did help. However now I am getting a new error:
In file included from /usr/include/osgQt/GraphicsWindowQt:21:0,
from /home/marc/OpenMW/openmw/apps/opencs/view/render/scenewidget.cpp:9:
/usr/include/osgQt/Version:8:2: error: #error "Qt version mismatch detected! Make sure to compile applications using osgQt with the same major Qt version that osgQt has been compiled against."
#error "Qt version mismatch detected! Make sure to compile applications using osgQt with the same major Qt version that osgQt has been compiled against."
Am I reading the version file correctly? It requires Qt5? Not cool.

Post Reply