Munt Reloaded - Development

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

Re: Munt Reloaded - Development

Postby HunterZ » 2015-11-09 @ 15:08

Thanks. How do I set that QT5 option? I'm not too familiar with cmake.
User avatar
HunterZ
l33t++
 
Posts: 6054
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby sergm » 2015-11-09 @ 15:25

HunterZ wrote:Thanks. How do I set that QT5 option? I'm not too familiar with cmake.


There are a number of ways :)
If you use ccmake or cmake-gui, it will appear very easy. You can also type
Code: Select all
cmake -D mt32emu-qt_WITH_QT5:BOOL=ON <path_to_sources>

on command line. Alternatively, you can lookup the property inside the CMakeCache.txt file and edit.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby marooned_on_mars » 2016-1-10 @ 18:46

Just got the latest commit from the git repo, and compiling the emulator libraries (mt32emu) works fine, but compiling anything else that depends on the libraries (like mt32emu_qt) ends up spewing those kinds of errors:

Code: Select all
Master.cpp:(.text+0x25a7): undefined reference to `MT32Emu::FileStream::FileStream()'
Master.cpp:(.text+0x2614): undefined reference to `MT32Emu::FileStream::open(char const*)'
Master.cpp:(.text+0x264a): undefined reference to `MT32Emu::ROMImage::makeROMImage(MT32Emu::File*)'
Master.cpp:(.text+0x266b): undefined reference to `MT32Emu::ROMImage::getROMInfo() const'
Master.cpp:(.text+0x26cb): undefined reference to `MT32Emu::FileStream::FileStream()'
Master.cpp:(.text+0x2738): undefined reference to `MT32Emu::FileStream::open(char const*)'
Master.cpp:(.text+0x2772): undefined reference to `MT32Emu::ROMImage::makeROMImage(MT32Emu::File*)'
Master.cpp:(.text+0x2793): undefined reference to `MT32Emu::ROMImage::getROMInfo() const'
CMakeFiles/mt32emu-qt.dir/src/Master.cpp.o: In function `Master::freeROMImages(MT32Emu::ROMImage const*&, MT32Emu::ROMImage const*&)':
Master.cpp:(.text+0x2aeb): undefined reference to `MT32Emu::ROMImage::getFile() const'
Master.cpp:(.text+0x2b11): undefined reference to `MT32Emu::ROMImage::freeROMImage(MT32Emu::ROMImage const*)'
Master.cpp:(.text+0x2b4b): undefined reference to `MT32Emu::ROMImage::getFile() const'
Master.cpp:(.text+0x2b71): undefined reference to `MT32Emu::ROMImage::freeROMImage(MT32Emu::ROMImage const*)'


I'll attach the full logs of the compilation attempts and CMake.
Is this a known issue, sergm, or did I mess something up?

Also, when I did a 'make install' (with root privileges of course) after compiling the libraries, not all the include files were transferred, so I had to copy them to /usr/local/mt32emu/ manually.
You do not have the required permissions to view the files attached to this post.
I support Universal Basic Income, and so should you, here's why. Another reason why.
Commonly asked questions about UBI
Spread the word!
User avatar
marooned_on_mars
Member
 
Posts: 361
Joined: 2006-1-23 @ 18:47
Location: MoonBase2

Re: Munt Reloaded - Development

Postby sergm » 2016-1-11 @ 07:58

That's not an issue. The library interface is in active development. When you compile the library stand-alone, it provides new API that the other components cannot use. There are corresponding compile options if you want to play with. I have some more thoughts about that and hopefully things will stabilize in a couple of weeks.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby gdjacobs » 2016-1-25 @ 14:43

What's the status of optimizing in the library, in general and in particular on ARM devices? If you've already mapped out some objectives, i would like to try to help.
User avatar
gdjacobs
l33t
 
Posts: 4259
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby Dominus » 2016-1-25 @ 16:41

Sergm: with the current qt-UI code it seems that changes in the properties are not saved on OS X.
I hit properties, set something, hit save, open again and almost all changes will be reverted (the "reverb enabled" drop down seems to stick). Is this intentional or is it a bug. Tsoliman on #munt is having the same issue (or actually he mentioned it and I confirmed).
User avatar
Dominus
DOSBox Moderator
 
Posts: 7308
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby sergm » 2016-1-25 @ 18:13

Donimus: No, I'm not aware of this behaviour. There is nothing like that I can see on Win/Linux/FreeBSD. Probably a Qt bug. Do you use Qt5? I sometimes observe very unpleasant things in Qt5 while it's in development...

gdjacobs: Nothing changed in that area. The general code style (at least within the library) is ANSI C compatibility, so I hope there is (almost) nothing to do to port it to the ARM arch. As for the speed, I expect today's mobiles are fast enough :)
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2016-1-25 @ 18:19

Donimus: Similar things might happen if you stop the synth and then try to change some settings. This is because the settings are stored in the synth's vars and then reloaded. If the synth is closed, some settings take no effect.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Dominus » 2016-1-25 @ 18:33

Yes, I've stopped the synth, changed stuff and then started it again. Seemed like the logical thing to me ;)

And yes, QT5.5(.1I think).
User avatar
Dominus
DOSBox Moderator
 
Posts: 7308
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby sergm » 2016-1-25 @ 18:47

OK, I'll commit a workaround for you personally :)
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby gdjacobs » 2016-1-25 @ 22:58

sergm wrote:gdjacobs: Nothing changed in that area. The general code style (at least within the library) is ANSI C compatibility, so I hope there is (almost) nothing to do to port it to the ARM arch. As for the speed, I expect today's mobiles are fast enough :)


It's fine as far as portability. My motivation is to achieve real time emulation on a platform like the Pi2. At present, a 1ghz Cortex A7 core can almost handle it, but not quite.

My sense is that most Munt development has been oriented to accuracy at present depending on general good coding practices to keep performance requirements in check. Do you have any thoughts on more radical optimizations which could be applied?
User avatar
gdjacobs
l33t
 
Posts: 4259
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby sergm » 2016-1-26 @ 07:32

When thinking about performance improvements, I guess, the best hopes should be set on using SSE-like intrinsics. However, we might not achieve a significant performance boost. The most CPU-demanding part is the sample generator in LA32WaveGenerator that emulates the LA32 chip. By the logic, the model heavily relies on the LUTs found within the chip, so the processing is quite problematic to do in parallel by a single processor core. The higher-level version of the emulation engine in LA32FloatWaveGenerator is much easier to speed up but it also significantly slower due to the use of floating-point computations (including sines and exponents).

Also, radical optimizations often end up with code harder to read, debug and maintain, which we'd like to avoid and keep the code as clear as possible. If there was a break-through optimization in the critical path, I think it would be worth to increase the code complexity. But instead, many of optimizations are compiler and/or platform specific, and therefore are not much desired.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby gdjacobs » 2016-1-26 @ 09:28

sergm wrote:When thinking about performance improvements, I guess, the best hopes should be set on using SSE-like intrinsics. However, we might not achieve a significant performance boost. The most CPU-demanding part is the sample generator in LA32WaveGenerator that emulates the LA32 chip. By the logic, the model heavily relies on the LUTs found within the chip, so the processing is quite problematic to do in parallel by a single processor core. The higher-level version of the emulation engine in LA32FloatWaveGenerator is much easier to speed up but it also significantly slower due to the use of floating-point computations (including sines and exponents).

Also, radical optimizations often end up with code harder to read, debug and maintain, which we'd like to avoid and keep the code as clear as possible. If there was a break-through optimization in the critical path, I think it would be worth to increase the code complexity. But instead, many of optimizations are compiler and/or platform specific, and therefore are not much desired.


Perfectly understandable. I wouldn't want a C preprocessor soup either.

I'll see how much time I've got, but I'd like to begin reading and familiarize myself with the code. You mind if I begin asking questions when the confusion sets in?
User avatar
gdjacobs
l33t
 
Posts: 4259
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby sergm » 2016-1-26 @ 10:22

No, I don't mind. But, be sure to create a topic for that, please :)
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby realnc » 2016-1-26 @ 13:00

Hand-written SSE should always be the last resort. Making sure data in hot loops always fits in the 64 byte CPU cache line and reducing data dependencies (so that the CPU core can auto-paralellize the code) is the most maintenance-friendly way of optimization.

Also, SSE code is the best way to prevent contributions since very few people understand this stuff :-P
realnc
Member
 
Posts: 143
Joined: 2010-10-13 @ 11:02

Re: Munt Reloaded - Development

Postby sergm » 2016-1-26 @ 17:24

Of course. I'd add that relying entirely on the optimization performed by the compiler is even more maintenance-friendly way, and that's what we practice ;)
Unfortunately, the algorithm in LA32WaveGenerator is already not quite easy to understand in contrast to the one in LA32FloatWaveGenerator. So, if a super-optimized version ever appears, it'll most probably be in a separate module.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby realnc » 2016-1-29 @ 09:40

Are you interested in patches for improving ABI compatibility in the C++ interface? I know it's more difficult to do in C++ compared to C, but I was thinking of introducing a d-pointer (aka "Pimpl idiom") and remove all private members from the headers. The exported classes would then only have public and protected members and thus any changes in the private members would not break the ABI.

Obviously doing this will break the current ABI, but that already happened now with the latest commit (making isActive() non-const).
realnc
Member
 
Posts: 143
Joined: 2010-10-13 @ 11:02

Re: Munt Reloaded - Development

Postby sergm » 2016-1-29 @ 09:51

Yep, the ABI was changed in that commit, but it had been also changed before that (so, I'm bumping the major version).
I think about a bit different approach for retaining C++ ABI compatibility further on. Moreover, I assume C++ API must fully correspond to the C and plugin ones. I'll add a facade class for that shortly (well, I should actually start from this point but I'll survive :) ).
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby gdjacobs » 2016-2-20 @ 02:28

Well, I don't know if I should slap myself on the back or in the face. The Broadcom CPU on the RPi 2 can successfully run Munt in real time, no dropped samples.
viewtopic.php?f=46&t=43524&p=479184#p479184

CXXFLAGS used, as recommended by ARM:
Code: Select all
-Ofast -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
Last edited by gdjacobs on 2016-2-26 @ 19:58, edited 1 time in total.
User avatar
gdjacobs
l33t
 
Posts: 4259
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby gdjacobs » 2016-3-29 @ 09:51

While working on ARM builds, mt32d and xmt32 were both found to segfault for recent git commits. I've performed a bisection analysis and believe I've located the problematic commit, but I would appreciate confirmation.

Here's the output:
Code: Select all
961ec3ce7d06974e10e3c786d505c21fb43f35c4 is the first bad commit
commit 961ec3ce7d06974e10e3c786d505c21fb43f35c4
Author: sergm <sergm@bigmir.net>
Date:   Sun Mar 6 19:42:05 2016 +0200

    - Public methods of Synth made protected from calling when the synth is closed

:040000 040000 521339dbc99a20d7577d9e5f35c2f03de2b69777 24095332e6319df14428fcc65ee44e4aa6218e52 M   mt32emu


Edit: I've confirmed that using the tree at the previous commit, 9939950, builds a fully functional mt32d. Using GDB determined the area of the segfault to be on the first call of getMT32Settings. My take is that the member variable opened is causing the segfault when the reverb constructor is called.

One mystery, though. I have no idea why it's doing it with mt32d and xmt32 and not mt32emu-qt.

Update: Apr. 4, 2016
Fault fixed in the latest git tree. Thanks, sergm!
User avatar
gdjacobs
l33t
 
Posts: 4259
Joined: 2015-11-03 @ 05:51
Location: The Great White North

PreviousNext

Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest