Switchres: modeline generator engine

[Calamity]

echo 0xffff > /sys/module/drm/parameters/debug

bash:  /sys/module/drm/parameters/debug: Permission denied

-------

BTW, Switchres does prompt Mame options, it was my fault I was typing -v-v-v instead of -v -v -v

[bitbytebit]

echo 0xffff > /sys/module/drm/parameters/debug

bash:  /sys/module/drm/parameters/debug: Permission denied

-------

BTW, Switchres does prompt Mame options, it was my fault I was typing -v-v-v instead of -v -v -v

Ah, yeah you have to use 'sudo -s' first before doing that so your the root user.

[Calamity]

It's working now, but it only produces a file named 'debug' with a '0' inside.

[bitbytebit]

It's working now, but it only produces a file named 'debug' with a '0' inside.

 

Oh, does the debug file exist already?, should be able to run 'cat  /sys/module/drm/parameters/debug' and see 65565 as the contents.  It may be the 2.6.36.2 version of the DRM code doesn't allow that to work, but in theory should after doing that see /var/log/messages fill up with information, I'm not sure why it's not taking the value echo'd into it though. 

[Calamity]

Yes, the 65535 is there before I run the second echo, so the messages should be in the messages file, ok, I'll get it now...

Here you have it, I've run glxgears maybe 2 or 3 times, tested both vblank_mode=2 / 3, the ones that fail, so there must be messages from several glxgears sessions there.

[newmanfamilyvlogs]

Here's the bottom half of a -v -v -v trying to run Crystal Castles. Notice the cannot initialize direct draw at the end.
Where do you think the problem is?

Code: [Select]

Got Soft15khz registry modeline 320x256@60 - DALDTMCRTBCD320x256x0x60:
             "320x256@60" 6.680000 320 336 368 416 256 257 260 268 -HSync -VSync

Setup monitor limits min=184x108 max=0x608
Starting with Horizontal freq of 16.949 and Vertical refresh of 61.04
Horizontal frequency too high 16.949 vfreq 61.035
Lowered horizontal frequency to  15700.000 from 16.949
Vertical frequency changed to 56.884 from 61.035
Original Vref 61.035156 != 56.884058
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vref Change | )
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62954/62967/62954) Modeline 6.650000 320 336 368 424 256 257 260 276
Opening  modes file for mode 320x256@57
Running Emulator: mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -
video ddraw -cleanstretch -redraw auto -throttle -mt
Target refresh = 61.035156
Target refresh = 61.035156
Unable to initialize DirectDraw.
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62967/62967/62967) Modeline 6.680000 320 336 368 416 256 257 260 268


[bitbytebit]

Here's the bottom half of a -v -v -v trying to run Crystal Castles. Notice the cannot initialize direct draw at the end.
Where do you think the problem is?

Code: [Select]

Got Soft15khz registry modeline 320x256@60 - DALDTMCRTBCD320x256x0x60:
             "320x256@60" 6.680000 320 336 368 416 256 257 260 268 -HSync -VSync

Setup monitor limits min=184x108 max=0x608
Starting with Horizontal freq of 16.949 and Vertical refresh of 61.04
Horizontal frequency too high 16.949 vfreq 61.035
Lowered horizontal frequency to  15700.000 from 16.949
Vertical frequency changed to 56.884 from 61.035
Original Vref 61.035156 != 56.884058
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Vref Change | )
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62954/62967/62954) Modeline 6.650000 320 336 368 424 256 257 260 276
Opening  modes file for mode 320x256@57
Running Emulator: mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -
video ddraw -cleanstretch -redraw auto -throttle -mt
Target refresh = 61.035156
Target refresh = 61.035156
Unable to initialize DirectDraw.
Setting registery video mode DALDTMCRTBCD320x256x0x60 with:
(62967/62967/62967) Modeline 6.680000 320 336 368 416 256 257 260 268


Are you able to run mame normally using -video ddraw, or does Direct Draw always fail?

Try this command line and see if mame runs...

mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -
video d3d -cleanstretch -redraw auto -throttle -mt

Possibly try ddraw, and use -verbose, fiddle around with the command line of just mame and see if you can figure out what works and what doesn't.  Guessing possibly your system doesn't do Direct Draw?  Also try to add '--args -video d3d' to switchres, which will force an override and use direct 3d instead.

[Calamity]

Hi cotmm68030,

First of all try to make sure that 320x256@60 video mode is actually available on your system. You can do it using Quickres (at the risk of having to restart in VGA mode in case the screen gets unreadable) or better use my Arcade_OSD little program for testing modes. Then you can also test Mame from the command line with the same params to see if it works:

mame ccastles -resolution 320x256@60 -resolution0 320x256@60 -video ddraw -cleanstretch -redraw auto -throttle -mt

ATI Catalyst drivers are hardcoded to doublescan 320x and 400x videomodes. That's why normally people are renaming them with 321x and 401x labels. If that's the case, you can try with my hacked drivers that remove that problem.

[newmanfamilyvlogs]

Well I came back to edit my post and ya'll had already jumped on it. I'm not sure what's going on because it worked running the same command line shortly thereafter.

DirectDraw has always worked on this system.

Calamity; I had planned on trying your drivers soon anyway.

However I'm still having issues launching switchres from Hyperspin. I'm thinking it's a file path issue. I'll post more when I've had more time to play with it and have a better understanding of whats going wrong.


Any plans of integrating switchres straight into a mame executable?

[bitbytebit]

Any plans of integrating switchres straight into a mame executable?

I've thought about it but also since mame is such a moving target and always changing it might make it hard to upkeep like advance mame was.  It is something that would be interesting but I've not explored it too far because I figure a wrapper like this essentially steers clear of worrying what the mame internals do.  It's pretty tricky from what I can tell to just keep the hiscore/cabmame patches up to date themselves, so something like this might be a total nightmare to keep updated.  I'm still hoping to figure out more internally how mame does the whole vertical refresh calculation and driving the game, maybe then I would be able to do something interesting enough to make it worth it.  The Advance mame code is interesting but everytime I look and try to understand it there's a big difference it seems between it and mame (maybe version or maybe it just altered mame quite a bit), and it's really difficult to understand because it seems to totally have different code paths per video card which makes it even more complicated.

[Calamity]

I've thought about it but also since mame is such a moving target and always changing it might make it hard to upkeep like advance mame was.  It is something that would be interesting but I've not explored it too far because I figure a wrapper like this essentially steers clear of worrying what the mame internals do.  It's pretty tricky from what I can tell to just keep the hiscore/cabmame patches up to date themselves, so something like this might be a total nightmare to keep updated.  I'm still hoping to figure out more internally how mame does the whole vertical refresh calculation and driving the game, maybe then I would be able to do something interesting enough to make it worth it.  The Advance mame code is interesting but everytime I look and try to understand it there's a big difference it seems between it and mame (maybe version or maybe it just altered mame quite a bit), and it's really difficult to understand because it seems to totally have different code paths per video card which makes it even more complicated.

I agree bitbytebit here, a wrapper is cleaner and allows extending this features to other emulators apart from Mame. There's just one case I think it would be better to have this integrated with Mame itself: many people are using GUI Mame builds, so games are launched there without the possibility of doing our stuff in the middle. So by now, Switchres is great for launching games from a frontend, provided it can be properly setup. Old AdvanceMenu is easy to setup for this, just using %s instead of %f to remove the .zip extension. AdvanceMame was updated until v0.106, after that they completely modified Mame video system, so the autor said it would require a complete rewrite of AdvanceMame to keep updated and left it there.

[newmanfamilyvlogs]

Yeah, I suppose just getting the front end to play nicely is a more robust solution than a series of one-off mame builds.

Another oddity I've noticed, when I exit from bitbytebit's mame compile, as launched by Hyperspin, Hyperspin does not seem to register that the program has terminated, and does not begin reading controls until you've tabbed away from and back into it.

I wonder what is happening differently here than any other mame build? Cabmame64 and MameUI64 both return to hyperspin correctly (even when launched via switchres).

[bitbytebit]

Yeah, I suppose just getting the front end to play nicely is a more robust solution than a series of one-off mame builds.

Another oddity I've noticed, when I exit from bitbytebit's mame compile, as launched by Hyperspin, Hyperspin does not seem to register that the program has terminated, and does not begin reading controls until you've tabbed away from and back into it.

I wonder what is happening differently here than any other mame build? Cabmame64 and MameUI64 both return to hyperspin correctly (even when launched via switchres).

I don't know if this might be part of the return issue, but the build I have is 32bit, so more like cabmame32.  Might be something, not sure why though it's not signaling a return to Hyperspin, and if that would be a cause of it. 

[bitbytebit]

Have version 1.254-5bc5179 ISO Images uploaded/uploading, the 32bit minimal is done uploading and rest will be there soon.  This uses OSS4 for the audio support, which may fix the sound issues since OSS4 is supposed to be a little better about things than Alsa (I already think it sounds better offhand, others claim that, old alsamixer doesn't work but doesn't matter because oss seems to unmute things by default but there's an ossxmixer and ossmixer if needed).  Also This has the 2.6.36 stable kernel but with the newest DRM code using the page flip support which now seems to get exact refresh rates and run the game speed at exactly 100% almost always except in rare cases it goes to 100.1%.  So it's pretty nice, there might be some more CPU usage from that it seems, but hopefully doesn't matter too much since most games are fine and if you have a 2.5Ghz core duo processor or better it should be even able to play the most heavy games (mine is 2.0 and it wants 2.4 or so Ghz it seems). 

Also another thing I'm wondering, from what I can tell if I run this with our vsync settings, but then add -throttle -mt I get things still without tearing.  If the game speed is already correct so we aren't actually utilizing throttle from what I can tell, it's just there to help us I'm guessing which probably will never happen from what I can tell.  So that also allows multi threading to work, I'm guessing because throttle does some thread safety stuff too by keeping things in sync probably.  So testing with '--args -throttle -mt' to switchres for games and comparing would be interesting, to see if there really is anything bad about throttle.  I'm still trying to explore the way mame multithreads, throttles, but from what I can tell with kernel page flipping and vblank/vsync support we are pretty good, I am wondering if throttle has some code that could be used to make multi threading work without throttle an waitvsync on still.  Somehow it's unifying the display output in multithreading mode, so maybe there's a way to do that and cut out anything bad that throttle might induce (which I don't see).  Also waiting for Alex to hopefully give an answer on why the CPU usage has went up and if this is just an outcome of being so exact on the scan line output to the monitor (which seems like in the code they have now timed it to the exact pixel to pefect refresh timing and timestamps for them to always know exactly what is being written from the OpenGL and X windows ati driver.   

[Calamity]

Also another thing I'm wondering, from what I can tell if I run this with our vsync settings, but then add -throttle -mt I get things still without tearing.  If the game speed is already correct so we aren't actually utilizing throttle from what I can tell, it's just there to help us I'm guessing which probably will never happen from what I can tell.  So that also allows multi threading to work, I'm guessing because throttle does some thread safety stuff too by keeping things in sync probably.

In my experience -throttle does not produce tearing but scroll hiccups. As our real screen vfreq and the one calculated by Mame internal clock will never match exactly, at some point one would not be able to catch the other. It's the classical problem of dealing with two clocks. Of course if we are very very close to the target it will be nearly perfect, but will still be there. For testing this, I always use sfa3, and look at the texts scrolling on the character selection screen. I noticed that even getting a nearly perfect vfreq I was seeing hiccups. That's why I figured out that syncrefresh patch I posted at the beginning of this thread, that didn't throttle in case sycrefresh was enabled (because at that time I had prejudices against triplebuffer, not anymore). Now we are getting the exact same visual result without patches just disabling throttle and enabling triplebuffering.

I didn't know the throttle option had anything to do with multithreading, but reading a bit more now, I'm seeing that sleep option there that points to that direction. As I understand it, throttling, vsyncing or whatever that involves doing loops to wait for stuff, need to have some 'sleep' mechanism implemented when working in a multitasking system, to allow the system share the cpu with other apps running, otherwise all cpu cycles would be wasted waiting there. This was not a problem in DOS realmode. By the way this one of the reasons why realtime apps in multitasking systems suck. If you 'sleep' your app for some time, it will be more friendly to the system, but I believe that you have to loose some accuracy with synchronization, as it's up to the system to give the control back to you when intended. This is my theory on what you're seeing with new drm, it could be trying to be so accurate it's leaving little time to the cpu for anything else. On the other hand, that per line accuracy is something we don't have in Windows at all, and seems it could make possible emulation of some original raster effects existing on real pcbs impossible to emulate otherwise.

[bitbytebit]

Switchres version 1.263-3d2f450 for Windows and Linux are up, they add...

* Vertical monitor support
* Rotatable monitor support
* custom aspect ratio calculation for vertical games on a horizontal monitor
* Finally got D9800 range correct, from what I can tell, to show pacman on it horizontally and keep original refresh rate
  (black hole area, I guess from 19Khz - ~20Khz, although it's possibly up to 22Khz and really not sure if it's even more complex and
   combo of line height of 288 in that range possibly or line total between 312-3?? can't be in that range)

Basically added a --mo arg for monitor aspect which takes 0 (default for horizontal monitor), 1 for vertical, 2 for rotatable monitor.   So it'll play a horizontal game correctly now on a vertical monitor, looks quite nice actually, was better than I thought it'd be on my 27" d9800.

The --vcalc arg now uses as before 0 for 16/9 true aspect calculation, 1 for 3/4 slightly wider calculation, and anything else is the value used (so 1.333 equals the 16/9 basically, since it does it slightly different in that 0 calculation and anything other than 1 which is done by height * (4/3), may be more ways to do this too I'm suspecting, the 0 though is probably what always should be used or 1 for people that like wider stretching to the games width on vertical games for a horizontal monitor).


Also with the ISO's, the newer DRM layer that is fully 100% accurate on game speed using the vsync, seems to not have any CPU usage increase in the 64bit kernel version?  So that's weird. only on 32bit does the increase occur, wondering if the accuracy of the vsync timestamping/page flipping is something which 64 bit seems to handle without problems while 32 bit seems to have to work a lot harder, but both are still nice as long as you have extra CPU for 32 bit.

[bitbytebit]

Also another thing I'm wondering, from what I can tell if I run this with our vsync settings, but then add -throttle -mt I get things still without tearing.  If the game speed is already correct so we aren't actually utilizing throttle from what I can tell, it's just there to help us I'm guessing which probably will never happen from what I can tell.  So that also allows multi threading to work, I'm guessing because throttle does some thread safety stuff too by keeping things in sync probably.

In my experience -throttle does not produce tearing but scroll hiccups. As our real screen vfreq and the one calculated by Mame internal clock will never match exactly, at some point one would not be able to catch the other. It's the classical problem of dealing with two clocks. Of course if we are very very close to the target it will be nearly perfect, but will still be there. For testing this, I always use sfa3, and look at the texts scrolling on the character selection screen. I noticed that even getting a nearly perfect vfreq I was seeing hiccups. That's why I figured out that syncrefresh patch I posted at the beginning of this thread, that didn't throttle in case sycrefresh was enabled (because at that time I had prejudices against triplebuffer, not anymore). Now we are getting the exact same visual result without patches just disabling throttle and enabling triplebuffering.

I didn't know the throttle option had anything to do with multithreading, but reading a bit more now, I'm seeing that sleep option there that points to that direction. As I understand it, throttling, vsyncing or whatever that involves doing loops to wait for stuff, need to have some 'sleep' mechanism implemented when working in a multitasking system, to allow the system share the cpu with other apps running, otherwise all cpu cycles would be wasted waiting there. This was not a problem in DOS realmode. By the way this one of the reasons why realtime apps in multitasking systems suck. If you 'sleep' your app for some time, it will be more friendly to the system, but I believe that you have to loose some accuracy with synchronization, as it's up to the system to give the control back to you when intended. This is my theory on what you're seeing with new drm, it could be trying to be so accurate it's leaving little time to the cpu for anything else. On the other hand, that per line accuracy is something we don't have in Windows at all, and seems it could make possible emulation of some original raster effects existing on real pcbs impossible to emulate otherwise.

Interesting, running sfa3 either way, throttle mt or nothrottle nomt, I see it as running perfectly either way.  So it seems possibly the page flipping and vblank support in the kernel is really running at exactly 100% and matching mame I guess enough or exactly.  At 64 bit on this d9800 the game is nice, amazing one to test with, thanks for letting me know about that as being a good test.  So many scrolling things all around, very interesting, and definitely seems like in that the Linux DRM layer is really doing some amazing things and even allowing the throttle option to still be used.  I'm guessing since the guy and others doing the work now are actually the employees of AMD and other companies for video cards/hardware they must be doing something possibly even better than they have done in the Windows for at least 2D for now and of course are with Gallium aiming to match that success with the 3D side of things.  From looking at the kernel code changes, they seem to be totally accounting for each exact scanline and pixel timestamp drawing to match the timing correctly with the vblank timestamps.  So from that it seems like it makes sense what I'm seeing, the jump all the sudden from near perfect running speed without throttle to perfect running speed, and possibly exact enough to even use throttle and it doesn't really matter (and then seems to allow multithreading too).  I also would think this means we should in theory be able to get multithreading working without throttle and just find the part that it needs to allow that to work with vsync support, at least remove most of what throttle does I would think and keep the part that allows the threads to be timed still and not just run free (It might be because they are depending on SDL->OpenGL to do the pageflip/vblank stuff, and need to do something to keep track of it so mame knows what is going  on, and not keep track of it through throttle and guess even though it seems to be guessing near perfectly now).

[Calamity]

I've been testing 1.254 iso (full). Now during the setup's "choose an audio device" part, it's saying "aplay: device_list:235: no soundcards found...", so can't choose anything as "Card number". After that, Gnome mixer is empty, no devices. However I tried with alsaconf and it's finding the same devices it did with the other iso, but there's no way I can make them work.

As you said, there must be a conflict with ATI HDMI and onboard audiocard, as it's strange both audio drivers are failing with this machine. However it's working ok in Windows. In the logs attached, notice these lines in messages file:

Jan  2 13:50:16 GroovyArcade kernel: [    1.618993] [drm] Enabling audio support

Jan  2 13:50:21 GroovyArcade kernel: [   99.606597] oss_hdaudio 0000:80:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Jan  2 13:50:21 GroovyArcade kernel: [   99.615479] oss_hdaudio: Too many connections
Jan  2 13:50:21 GroovyArcade kernel: [   99.615540] oss_hdaudio: HDA codec 0x00000000 not known yet

Why should drm be messing with audio? (I guess that's because it's the videocard's HDMI)
(these logs are without running alsaconf, just with the out of the box setup).

[bitbytebit]

I've been testing 1.254 iso (full). Now during the setup's "choose an audio device" part, it's saying "aplay: device_list:235: no soundcards found...", so can't choose anything as "Card number". After that, Gnome mixer is empty, no devices. However I tried with alsaconf and it's finding the same devices it did with the other iso, but there's no way I can make them work.

As you said, there must be a conflict with ATI HDMI and onboard audiocard, as it's strange both audio drivers are failing with this machine. However it's working ok in Windows. In the logs attached, notice these lines in messages file:

Jan  2 13:50:16 GroovyArcade kernel: [    1.618993] [drm] Enabling audio support

Jan  2 13:50:21 GroovyArcade kernel: [   99.606597] oss_hdaudio 0000:80:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Jan  2 13:50:21 GroovyArcade kernel: [   99.615479] oss_hdaudio: Too many connections
Jan  2 13:50:21 GroovyArcade kernel: [   99.615540] oss_hdaudio: HDA codec 0x00000000 not known yet

Why should drm be messing with audio? (I guess that's because it's the videocard's HDMI)
(these logs are without running alsaconf, just with the out of the box setup).

Yeah the setup error is just it trying to check for Alsa and it not existing, in the next ISO it'll give an option to use either Alsa or OSS at that point instead of trying to immediately mess with the mixer.  It seems it is more of an issue in Linux possibly and both Alsa and OSS are having trouble with that soundcard, strange.  I have a system that required Alsa instead of OSS, so seems it's variable for each system, although I suspect Alsa might be more compatible to more cards but the ones OSS works for work better than Alsa.  

Send me the output of these commands (after sudo -s)
lspci -v -v -v > lspci_output.txt
ossinfo > ossinfo_output.txt

Also running ossdetect might be interesting to see what it does.  I am wondering if oss just isn't loading the right module, could also try 'modprobe oss_ich' to see if that finds it.  I'll look through the logs and try to find more info on those errors, I do see people have issues with those sounds cards sometimes and seems like it's possibly just certain ones with certain setups.



Update:

Also get the /var/log/soundon.log file, seems that really shows a lot of information.

[Calamity]

Here are the outputs of lspci and ossinfo. I'm running ossdetect and modprobe oss_ich but they just end silently without prompting anything.
I've been trying some youtube videos on the browser and there's no sound there either.

UPDATE: soundon.log attached.

[bitbytebit]

Here are the outputs of lspci and ossinfo. I'm running ossdetect and modprobe oss_ich but they just end silently without prompting anything.
I've been trying some youtube videos on the browser and there's no sound there either.

UPDATE: soundon.log attached.

Does ossxmixer have anything in it that can be unmuted?  Or volume turned up, that mixer should work (although it is really larger than the 640x480 screen I admit :/).  Also ossmix is a command line version of it.

Update:

Interesting, the one thing that might be happening is perhaps it's using the HD mode of the card instead of the Analog one?  I see your card actually is similar to mine but yet has the whole right/left outputs...

Mine:

Code: [Select]

Audio devices:
0: HD Audio play speaker (OUTPUT)
1: HD Audio play headphone (OUTPUT)
2: HD Audio rec mix (INPUT)
3: HD Audio rec mix (INPUT)
4: HD Audio rec mix (INPUT)

Yours:

Code: [Select]

Audio devices:
0: HD Audio play front (OUTPUT)
1: HD Audio play rear (OUTPUT)
2: HD Audio play center/LFE (OUTPUT)
3: HD Audio play c/lfe (OUTPUT)
4: HD Audio play pcm (OUTPUT)
5: HD Audio play pcm (OUTPUT)
6: HD Audio rec  (INPUT)
7: HD Audio rec  (INPUT)
8: HD Audio rec  (INPUT)
9: HD Audio rec  (INPUT)

It does see it so getting more than Alsa does, and actually looks like it's setup and just that one error we see, like it's trying to do both HD and Analog audio at the same time or something like that.


Update:

Also ossmix -c output is interesting, may show some things possible to change and it outputs the actual command you need to run (removing the first ! part) to alter it, 25 is max volume, see if anthing interesting is muted, although if you can see ossxmix output that might be better.  If you want, send me the output of ossmix -c too, that at least will show exactly the current mixer settings.

Update:

Also does the computer have an audio jack output on the front too, does it output sound?  Definitely weird, your sound card has a lot of outputs according to oss, can see why something odd might be going on and confusing things in Linux. 

[Calamity]

ossmixer command is not recognized.
ossmix is prompting this:

Code: [Select]

Selected mixer 0/High Definition Audio ALC662
Known controls are:
vmix0-enable ON|OFF (currently ON)
vmix0-rate <decimal value> (currently 48000) (Read-only)
vmix0-channels <Stereo|Multich> (currently Stereo)
vmix0-src <Fast|High|OFF> (currently Fast)
vmix0-outvol <monovol> (currently 25.0 dB)
vmix0-invol <monovol> (currently 25.0 dB)
vmix0.pcm10 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm11 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm12 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm13 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
UPDATE: ossmix -c

Code: [Select]

!ossmix -d0 vmix0-enable ON
!ossmix -d0 vmix0-channels Stereo
!ossmix -d0 vmix0-src Fast
!ossmix -d0 vmix0-outvol 25.0
!ossmix -d0 vmix0-invol 25.0
!ossmix -d0 vmix0.pcm10 25.0:25.0
!ossmix -d0 vmix0.pcm11 25.0:25.0
!ossmix -d0 vmix0.pcm12 25.0:25.0
!ossmix -d0 vmix0.pcm13 25.0:25.0


[bitbytebit]

ossmixer command is not recognized.
ossmix is prompting this:

Code: [Select]

Selected mixer 0/High Definition Audio ALC662
Known controls are:
vmix0-enable ON|OFF (currently ON)
vmix0-rate <decimal value> (currently 48000) (Read-only)
vmix0-channels <Stereo|Multich> (currently Stereo)
vmix0-src <Fast|High|OFF> (currently Fast)
vmix0-outvol <monovol> (currently 25.0 dB)
vmix0-invol <monovol> (currently 25.0 dB)
vmix0.pcm10 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm11 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm12 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
vmix0.pcm13 [<leftvol>:<rightvol>] (currently 25.0:25.0 dB)
UPDATE: ossmix -c

Code: [Select]

!ossmix -d0 vmix0-enable ON
!ossmix -d0 vmix0-channels Stereo
!ossmix -d0 vmix0-src Fast
!ossmix -d0 vmix0-outvol 25.0
!ossmix -d0 vmix0-invol 25.0
!ossmix -d0 vmix0.pcm10 25.0:25.0
!ossmix -d0 vmix0.pcm11 25.0:25.0
!ossmix -d0 vmix0.pcm12 25.0:25.0
!ossmix -d0 vmix0.pcm13 25.0:25.0


Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue.  


Update:

In the source I see that MAX_CONN value seems to be 24 and that's the amount of audio devices + audio engines + mixer devices you have so far.  I suspect it's hitting that limit, I am raising that limit and will see what it does, hopefully get an ISO in a few hours up that has that raised if I have luck with it here not causing things to break.  At least good that my soundcard is the same type so can test to make sure it still allows it to work, actually uses the same module but yours I guess is a much higher revision than mine (ALC262).

[Calamity]

Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue. 

I've plugged the speakers to each of the five jack connectors I have while playing a video. No sound. I always have them connected to the green one (front) and get sound normally. This is definitely weird.

I must have a curse with Linux and sound, I've been trying different live-cds for years, in three different computers at least, different distributions (Suse...), different hardware (creative, realtek) and have never been able to hear a single beep out of it.

[bitbytebit]

Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue. 

I've plugged the speakers to each of the five jack connectors I have while playing a video. No sound. I always have them connected to the green one (front) and get sound normally. This is definitely weird.

I must have a curse with Linux and sound, I've been trying different live-cds for years, in three different computers at least, different distributions (Suse...), different hardware (creative, realtek) and have never been able to hear a single beep out of it.

I'm uploading a new ISO LiveCD32-Mini-NMO-1.269-accf1fe.iso which has increased that limit which it's complaining about.  Well all the Linux distributions have used Alsa, hopefully this OSS4 can figure things out.  Definitely sounds like a bit of bad luck of what sound cards are on those systems.  If you research it turns out many are unhappy with how Linux audio has been done.  Unfortunately a lot of it is the proprietary nature of sound cards chips, so hard to fight that.  OSS and Alsa have interesting histories which both make people unhappy with how they've been done.  Hopefully sooner or later OSS4 is either advanced to the point of fixing the issue completely or Alsa figures out the issues there.  Seems like a lot of things need to be done though before either could happen.  At least it sees the card and we have that error to work off of and curious what this ISO says about that, hopefully doubling the 24 to 48 is enough audio connections.

[bitbytebit]

Just odd, it seems to all be setup ready to play, I expected some errors from oss but the only one is that log one.  Odd thing is I can't find that error for anyone else when searching for it in Google, so not a common error or it's maybe harmless and there's something else that's the issue.  

I've plugged the speakers to each of the five jack connectors I have while playing a video. No sound. I always have them connected to the green one (front) and get sound normally. This is definitely weird.

I must have a curse with Linux and sound, I've been trying different live-cds for years, in three different computers at least, different distributions (Suse...), different hardware (creative, realtek) and have never been able to hear a single beep out of it.

Also if OSS in the new ISO doesn't work, here's an interesting thing to try from this bug report (seems others see problems too with this exact card/chip)...

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/664785

Strangely this is related to bug#536699. Changing, in the BIOS, the graphics aperture size from 128MB to 256MB as suggested in that bug's comments solves both that issue and this.

I'd try OSS, then OSS with this change, and if that doesn't work then try Alsa with the change.  I can kind of see that it could make sense with the video card having essentially the same type of audio chip in it and maybe the BIOS has some issue when it's not large enough aperture.  Of course one person said they don't even have that option in the BIOS, a long shot but definitely interesting to see others with the issue lately (seems older Ubuntu versions didn't but 10.10 does have this bug).

Oddly at the end of this bug report that one references, multiple people found this as the solution...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/536699


Update:
Also here's something interesting to try...

sudo -s
ossdetect -v
soundoff
rmmod oss_hdaudio
rmmod oss_usbaudio
rmmod osscore
rm -f /etc/oss/installed_drivers
soundon

Then check ossmix -c and see if it's different, and try some audio then.

Which might setup things better, now have figured out that is what is necessary for each system setup, it was really just setting up OSS4 for my setup.  The OSS4 stuff lacks a bit of smoothness in how it installs, seems to not be aimed at generic detection on load unless you do the above each time.


Update: Also to test, run osstest this command is great, best way to see if audio is working.

[Calamity]

Thanks a lot for the info and links. I'll test those today. The bios aperture option however will be more difficult to test as I can't see the bios through the jpac anymore since I installed this 4350 card. It's so distorted I can barely see anything on the upper part of the screen. I'd need to get a pc monitor to do that. I also want to have a look at the new options in Switchres and how they work. I've been studying your code a little bit, to see if I can help with the video mode selection algorithm, will take me some time. I want to test some ideas of how to precalculate a mode table, it would be interesting to try to get the best possible out of driver limited to 60 modes also. I was also having a look at the PLL code in radeon drivers, can't figure out much of it yet but definitely interesting, and good to know it's coming directly from AMD.

[Calamity]

Audio is finally working! 

It seems your patch increasing the number of devices was the key, so that should be reported or something as there must be more people having the same problem.

So the osstest command is working, btw this is just what I was needing, a simple command to test sound.

However sound does not work yet in Mame. By default it's trying to setup an ALSA device (fails). Then I've tried to force it to select oss on the audiodriver sdl option, I've tried oss_hdaudio0, then the ALSA errors stop, but it says it's finding no audio device

I'll post some logs later.

[bitbytebit]

Audio is finally working!  

It seems your patch increasing the number of devices was the key, so that should be reported or something as there must be more people having the same problem.

So the osstest command is working, btw this is just what I was needing, a simple command to test sound.

However sound does not work yet in Mame. By default it's trying to setup an ALSA device (fails). Then I've tried to force it to select oss on the audiodriver sdl option, I've tried oss_hdaudio0, then the ALSA errors stop, but it says it's finding no audio device

I'll post some logs later.

Try to have it use 'dsp' for the -audiodriver, that's what it uses here when it works with oss.

[Calamity]

It's working! It was not necessary to set the audiodrive to dsp, it was already working but very low for some reason, now I have set the ossmix jack.green.front 64:64 (it was 51 or something) and set the speakers' volume to the top and it's sounding normal. So it may be sounding lower that in Windows it seems, not sure however as some Mame games sound louder than others, need to do more tests.

Some logs attached: mame.log (only is first part of it) shows no alsa errors any more (were they prompted by switchres or mame itself?), everything looks ok. In messages file there's not that  "too many devices error" any more.

[bitbytebit]

It's working! It was not necessary to set the audiodrive to dsp, it was already working but very low for some reason, now I have set the ossmix jack.green.front 64:64 (it was 51 or something) and set the speakers' volume to the top and it's sounding normal. So it may be sounding lower that in Windows it seems, not sure however as some Mame games sound louder than others, need to do more tests.

Some logs attached: mame.log (only is first part of it) shows no alsa errors any more (were they prompted by switchres or mame itself?), everything looks ok. In messages file there's not that  "too many devices error" any more.

Sounds great, I'll have to send the fix to the OSS people, definitely starting to like the way OSS4 is now that I realized the way to initialize the card detection after the first install.  It may actually partly be my setup turning the volume output down from 25 to 18, on my cab I do that to keep it from blaring but I also have a pga golf tour that for some reason came with huge car speakers that need a 150Watt audio amp and are very loud at full volume .  So guessing that's something I probably shouldn't turn down for every setup, although I'm turning down the audio output and seems your sound card has other settings there which I've never touched here yet (or know if they exist on mine).  I have been pretty impressed with OSS4 after I hacked it quite a bit to the current state so it behaves on the liveCD properly and can be setup in my chroot, and that fix and a few others. 

I'll have new ISO images up soon that do all the initialization stuff internally instead of you having to run those commands each boot.  I think even alsa behaves better now with they way I have it when enabled, possibly could even get alsa working there because it now works easily on my laptop which I think was very similar to your situation (of course OSS4 sounds better I think and probably better, but would be interesting to test that on the next ISO). 

Also it might be interesting to see if the debug we did for the DRM layer is any different on these new ISO images since they are now using the newer DRM and page flipping, might show more information.  Hopefully Alex eventually figures that out, I'm pretty much lost because from the log I just see there's no interrupts occurring even though it's trying to set the registers to trigger them.  Possibly the newer DRM has better debug messages, they've improved them quite a bit over the last month since that stable kernel that the others messages came from.


I'm looking into this http://www.glfw.org/ right now, it's interesting because it seems like a very easy to use simple yet powerful SDL/Mesa replacement to use OpenGL through an interface that simplifies the programming and doesn't require the whole SDL->OpenGL stuff.  Which I'm suspecting would allow multithreading and vsync to work together and the video mode and vsync setup in general to work better.  I don't really like SDL the more I see how they basically froze 1.2 and 1.3 is the never ending development version that is really breaking things faster than improving them.  Also if broken off into a separate osd then I can put the switchres program into it possibly, if it really seems feasible to rewrite the osd using this glfw interface.  It'll at least teach me more about how mame does the OSD, by trying to build a new one, right now I'm starting just having it be a separate -video option for SDL but can see how it really needs to be a whole separate OSD since it can do all the stuff SDL does and looks way simpler to implement with glfw.  I discovered it a little while ago while looking up the OpenGL functions and finding people that were trying to do Vsync and having issues with SDL and were recommended  to try glfw and everyone seemed to have all their problems fixed by it and see perfect vsync (which we do have currently somewhat but I'm guessing we can multithread and reduce overhead/CPU usage, possibly improve the whole OSD feel having it really multithread everything and just keep the main frame vsync write in OpenGL/glfw as a single thread). 

[bitbytebit]

I've got version 1.274-edcf26b ISO images up, should be all built in to use OSS4 correctly now and generally work really well besides the J-Pac issue with the 4350 and the odd 32 bit CPU usage from the page flipping. 

Both issues hopefully sooner or later will be addressed by Alex.  I'm going to start digging into the kernel more and see if I can at all figure out why it'd not run interrupts for vblanking when the interface doesn't detect a monitor but is forced on.  I think that GLFW library is somewhat a dead end for now from lack of extra stuff that SDL provides, input layer doesn't look great and besides full screen mode not working as expected it doesn't have sound or font/text OSD writing.  Figures, I also am thinking the mame multithreading probably isn't going to work with vsync, from taking it apart quite a bit on the OSD side the last day I just see that it seems to be most likely impossible or a very big job to multithread it without throttling and using the vsync.  I still am poking at it, but definitely not any leads really on how to do it yet.

[Calamity]

Just out of curiosity, do you mean that multithreading only works when enabling throttle, or is the vsync itself what prevents it from working? By reading mame's windows.txt, it seems multithreading just creates a second thread for the window + d3d/ddraw management. So both threads should be synchronized in order to work. Could it be that the synchronization code is inside the throttle part?. Honestly I have no idea of how they are doing it.

Hopefully tomorrow I'll send you the drm debug logs so they can help you or Alex figure out what's going on, must be something silly about not really using the forced connections. Definitely eager to see that solved as it seems the last remaining wall to pull down in order to have this working for everyone, once there's a fully working version I'd like to install it to the hardrive so I don't have to run the setup all the time

[bitbytebit]

Just out of curiosity, do you mean that multithreading only works when enabling throttle, or is the vsync itself what prevents it from working? By reading mame's windows.txt, it seems multithreading just creates a second thread for the window + d3d/ddraw management. So both threads should be synchronized in order to work. Could it be that the synchronization code is inside the throttle part?. Honestly I have no idea of how they are doing it.

Hopefully tomorrow I'll send you the drm debug logs so they can help you or Alex figure out what's going on, must be something silly about not really using the forced connections. Definitely eager to see that solved as it seems the last remaining wall to pull down in order to have this working for everyone, once there's a fully working version I'd like to install it to the hardrive so I don't have to run the setup all the time

Without throttle there seems to be no way to run the threads in the work queue timed with the vsync, so without multithread it follows the vsync fine but when executing the window drawing event.  When it puts the window drawing event into that work queue though it seems to just go as fast as it can without throttle.  Without vsync or with it is the same, when throttle is taken out for SDL Linux, things just run full speed unless you have the vsync set, and multithreading off.  So somehow vsync and no multithreading allow nothrottle to run at the correct speed and not run out of control.  It's odd because I don't see it explicitly stated anywhere about that, not sure if it's a newer bug and used to not be that way in older mame versions, possibly since in Linux few have had the ability to use vsync properly without throttle they've never addressed the issue or might not even know it exists.   

Yeah I just installed the current system to my hard drive and now that will be my development system, so the system is now going to be developed within the system .  Which is nice and actually will get to use it with the page flip stuff now all the time, my old setup was the original system I built before the liveCD one and so ran at the ~2% off of actual refresh rate and setup as more of a proof of concept.  There are a few little parts of setup that aren't 100% smoothed up on installing, which I just saw today, so still have those to take care of.

I'm actually amazed the last few days, every way I cut it seems the newest DRM is running exactly 100% or sometimes 100.01% or 99.99%, it's never more than .01% off on game speed.  So whatever they did, probably the vblank timestamping I would guess, they made it really work perfectly now (at the expense of a bit of CPU on 32 bit kernels unfortunately for now).  So if the connector interrupt issue and the CPU usage issue is figured out, should be quite a useful system.  I also still need to go through all the emulators and setup each to allow switchres to work with them and go into full screen properly etc.  I had that working in the past, be it was before with different switchres command line syntax and also the nes emulators and gens are weird about full screen and getting it right at the original resolution.  Basically have run them all like that, but boxing it all up into a simple wahcade instant config is a pain, plus wahcade setup itself is not the greatest of ease unfortunately.

[Calamity]

I'm seeing the same issue with nothrottle + multithreading in the Windows version, crazy CPU usage when nothrottle included, so it definitely seems a problem with Mame design. I've been looking through the code and have some idea of how to solve it rather easily, however I'm not sure if that will break something else. On the other side patching Mame is discouraging as it may turn out to be useless with next version, etc.

So for what I'm seeing now with multithreading they're doing two threads:

- Window thread: that deals with window managment and ddraw/direct3d (where vsync happens)
- Main thread: the emulator itself, that creates a frame at a time

By the way, this is the desing that should be the default for Mame, as single threaded emulators are crap as the sound gets stuck in a loop when they are minimized.

So the main thread creates a frame, and if throttle is enabled, then runs update_throttle(current_time) in \emu\video.c, which calls throttle_until_ticks, which at the end calls osd_sleep(delta) where the 'sleep' is actually done. So if you disable throttle, the sleep of the thread is not performed, that's why it's eating all cpu cycles.

Code: [Select]

// if we're throttling, synchronize before rendering
attotime current_time = timer_get_time(&m_machine);
if (!debug && !skipped_it && effective_throttle())
update_throttle(current_time);

// ask the OSD to update
g_profiler.start(PROFILER_BLIT);
m_machine.osd().update(!debug && skipped_it);
g_profiler.stop();
The waiting for vsync, however, is performed in the d3d/ddraw part. So if we have a single thread, the processor will wait there and Mame will be synchronized despite disabling throttle, although wasting all cpu time.

But when we start both threads, then the main thread is not aware of the window thread waiting! (as they run in paralell) and keeps sending frames to it all the time regardless vsync, unless we enable throttle.

So what should be done is to create an event object in order to synchronize both threads. This is done (in Windows) with the CreateEvent api. So, after creating a frame the main thread would do a WaitForSingleObject to release the cpu until we order it to go on with the next one. In the window thread, we would wait for vsync, and when done, we would use SetEvent, to instruct the other thread to go on. In theory this would make a better use of cpu.

So the throttle logic should be replaced when doing vsync, from the current sleep for some ticks (that is causing scroll hiccups for me), to the event ruled method above.

[bitbytebit]

I'm seeing the same issue with nothrottle + multithreading in the Windows version, crazy CPU usage when nothrottle included, so it definitely seems a problem with Mame design. I've been looking through the code and have some idea of how to solve it rather easily, however I'm not sure if that will break something else. On the other side patching Mame is discouraging as it may turn out to be useless with next version, etc.

So for what I'm seeing now with multithreading they're doing two threads:

- Window thread: that deals with window managment and ddraw/direct3d (where vsync happens)
- Main thread: the emulator itself, that creates a frame at a time

By the way, this is the desing that should be the default for Mame, as single threaded emulators are crap as the sound gets stuck in a loop when they are minimized.

So the main thread creates a frame, and if throttle is enabled, then runs update_throttle(current_time) in \emu\video.c, which calls throttle_until_ticks, which at the end calls osd_sleep(delta) where the 'sleep' is actually done. So if you disable throttle, the sleep of the thread is not performed, that's why it's eating all cpu cycles.

Code: [Select]

// if we're throttling, synchronize before rendering
attotime current_time = timer_get_time(&m_machine);
if (!debug && !skipped_it && effective_throttle())
update_throttle(current_time);

// ask the OSD to update
g_profiler.start(PROFILER_BLIT);
m_machine.osd().update(!debug && skipped_it);
g_profiler.stop();
The waiting for vsync, however, is performed in the d3d/ddraw part. So if we have a single thread, the processor will wait there and Mame will be synchronized despite disabling throttle, although wasting all cpu time.

But when we start both threads, then the main thread is not aware of the window thread waiting! (as they run in paralell) and keeps sending frames to it all the time regardless vsync, unless we enable throttle.

So what should be done is to create an event object in order to synchronize both threads. This is done (in Windows) with the CreateEvent api. So, after creating a frame the main thread would do a WaitForSingleObject to release the cpu until we order it to go on with the next one. In the window thread, we would wait for vsync, and when done, we would use SetEvent, to instruct the other thread to go on. In theory this would make a better use of cpu.

So the throttle logic should be replaced when doing vsync, from the current sleep for some ticks (that is causing scroll hiccups for me), to the event ruled method above.

Patching it shouldn't be a problem, I should be able to keep up with it, just might take a few days when they change things enough.  I've been studying the code and see exactly what your saying.

I just did a test as a proof of concept and it works with a very rudementry lock it seems for the test, of course need something better than this which is pretty crude...

Code: [Select]

diff --git a/src/osd/glfw/drawogl.c b/src/osd/glfw/drawogl.c
index 1844dcc..adc2cfc 100644
--- a/src/osd/glfw/drawogl.c
+++ b/src/osd/glfw/drawogl.c
@@ -1551,6 +1552,9 @@ static int drawogl_window_draw(sdl_window_info *window, UINT32 dc, int update)
 #else
        SDL_GL_SwapWindow(window->sdl_window);
 #endif
+
+       window->update_ok = 0;
+
        return 0;
 }

diff --git a/src/osd/glfw/video.c b/src/osd/glfw/video.c
index 12e77db..c6d3060 100644
--- a/src/osd/glfw/video.c
+++ b/src/osd/glfw/video.c
@@ -329,6 +329,7 @@ sdl_monitor_info *sdlvideo_monitor_from_handle(UINT32 hmonitor)
 //  update
 //============================================================
 
+#include <unistd.h>
 void sdl_osd_interface::update(bool skip_redraw)
 {
        sdl_window_info *window;
@@ -343,6 +344,11 @@ void sdl_osd_interface::update(bool skip_redraw)
        {
 //      profiler_mark(PROFILER_BLIT);
                 for (window = sdl_window_list; window != NULL; window = window->next) {
+                       if (window->update_ok == 1)
+                               while(window->update_ok == 1)
+                                       usleep(10000);
+                       window->update_ok = 1;
+
                         sdlwindow_video_window_update(&machine(), window);
                         if (machine().redraw != 0)
                         {

--- a/src/osd/glfw/window.c
+++ b/src/osd/glfw/window.c
@@ -1012,8 +1018,10 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
-               }
-       }
+               } else
+                       window->update_ok = 0;
+       } else
+               window->update_ok = 0;
 }
 
 
diff --git a/src/osd/glfw/window.h b/src/osd/glfw/window.h
index f488652..075959e 100644
--- a/src/osd/glfw/window.h
+++ b/src/osd/glfw/window.h
@@ -93,6 +93,8 @@ struct _sdl_window_info
        // GL specific
        int                                     prescale;
 
+       int                                     update_ok;
+
 #if (SDL_VERSION_ATLEAST(1,3,0))
        // Needs to be here as well so we can identify window
        SDL_Window                      *sdl_window;





Crude but it does keep it 100% that way with multithreading and need to test more but should in theory allow the threading to go above 100% cpu usage and use both CPU's?  I'm not sure though, but does this look like the right way places to lock like this?  Seems to be pretty good at running now like that right off, so at least doesn't hurt anything and still can use the multithread work queue.

[Calamity]

Yeah that's the idea. I'm not familiar with the SDL code in Mame. However I would try to place the sleeping in the update_throttle function itself, doing two branches inside it in case we're vsyncing or not, so that part would be common for both Windows/Linux, and then have the SDL/DDraw on the other part triggering the event.

Do you mean the CPU usage is still 100%? At least in theory, each of those threads could be run in one of the two processors, but it could be up to the system to do that. Anyway I have no experience with that, I've just done multithreading for single processors.

[bitbytebit]

Yeah that's the idea. I'm not familiar with the SDL code in Mame. However I would try to place the sleeping in the update_throttle function itself, doing two branches inside it in case we're vsyncing or not, so that part would be common for both Windows/Linux, and then have the SDL/DDraw on the other part triggering the event.

Do you mean the CPU usage is still 100%? At least in theory, each of those threads could be run in one of the two processors, but it could be up to the system to do that. Anyway I have no experience with that, I've just done multithreading for single processors.

Oh no just running at 100% speed, cpu usage is a little more that way but I just figured out how to use the built in pthread locking they already have for the rendering queue.  With that it's exactly the same as before in CPU usage and running speed percent but multithreading enabled too.

Code: [Select]

diff --git a/src/osd/glfw/drawogl.c b/src/osd/glfw/drawogl.c
index 1844dcc..7c60225 100644
--- a/src/osd/glfw/drawogl.c
+++ b/src/osd/glfw/drawogl.c
@@ -1551,6 +1552,10 @@ static int drawogl_window_draw(sdl_window_info *window, UINT32 dc, int update)
 #else
        SDL_GL_SwapWindow(window->sdl_window);
 #endif
+
+       // Vsync multithreading lock release
+       osd_event_set(window->vsync_flip);
+
        return 0;
 }

diff --git a/src/osd/glfw/video.c b/src/osd/glfw/video.c
index 12e77db..e1d8313 100644
--- a/src/osd/glfw/video.c
+++ b/src/osd/glfw/video.c
@@ -329,6 +329,7 @@ sdl_monitor_info *sdlvideo_monitor_from_handle(UINT32 hmonitor)
 //  update
 //============================================================
 
+#include <unistd.h>
 void sdl_osd_interface::update(bool skip_redraw)
 {
        sdl_window_info *window;
@@ -343,6 +344,8 @@ void sdl_osd_interface::update(bool skip_redraw)
        {
 //      profiler_mark(PROFILER_BLIT);
                 for (window = sdl_window_list; window != NULL; window = window->next) {
+                       osd_event_wait(window->vsync_flip, 20000);
+
                         sdlwindow_video_window_update(&machine(), window);
                         if (machine().redraw != 0)
                         {

diff --git a/src/osd/glfw/window.c b/src/osd/glfw/window.c
index 7d21423..967d3b4 100644
--- a/src/osd/glfw/window.c
+++ b/src/osd/glfw/window.c
@@ -698,6 +704,7 @@ int sdlwindow_video_window_create(running_machine *machine, int index, sdl_monit
 
        // create an event that we can use to skip blitting
        window->rendered_event = osd_event_alloc(FALSE, TRUE);
+       window->vsync_flip = osd_event_alloc(FALSE, TRUE);
 
        // load the layout
        window->target = machine->render().target_alloc();
@@ -793,6 +800,7 @@ static void sdlwindow_video_window_destroy(running_machine *machine, sdl_window_
 
        // free the event
        osd_event_free(window->rendered_event);
+       osd_event_free(window->vsync_flip);
 
        // free the window itself
        global_free(window);
@@ -1012,8 +1020,10 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
-               }
-       }
+               } else
+                       osd_event_set(window->vsync_flip);
+       } else
+               osd_event_set(window->vsync_flip);
 }
 
 diff --git a/src/osd/glfw/window.h b/src/osd/glfw/window.h
index f488652..23a27fc 100644
--- a/src/osd/glfw/window.h
+++ b/src/osd/glfw/window.h
@@ -93,6 +93,8 @@ struct _sdl_window_info
        // GL specific
        int                                     prescale;
 
+       osd_event *                             vsync_flip;
+
 #if (SDL_VERSION_ATLEAST(1,3,0))
        // Needs to be here as well so we can identify window
        SDL_Window                      *sdl_window;




As you can see, this is exactly the same type of wait they use for the render event in the osd update function, except in that they just signal it and never really wait since the timeout is set to 0 for it for some reason.  I'm not sure if there's a better function to use for the osd_event * vsync_flip, but I'm pretty sure it's close (maybe the locking functions instead of the waiting ones?).

It sounds good to put that into the throttle part, I need to see how to allow that access to the osd_event, think I can make an update type function which calls the wait possibly.

The windows part seems to be able to lock a similar way, of course can make a different vsync_flip type function for both OSD types if it needs to be different.  It's actually interesting seeing the difference between the windows way and sdl linux way of doing this for the osd...


Windows:

Code: [Select]

        // if we're visible and running and not in the middle of a resize, draw
        if (window->hwnd != NULL && window->target != NULL && window->drawdata != NULL)
        {
                int got_lock = TRUE;

                mtlog_add("winwindow_video_window_update: try lock");

                // only block if we're throttled
                if (window->machine->video().throttled() || timeGetTime() - last_update_time > 250)
                        osd_lock_acquire(window->render_lock);
                else
                        got_lock = osd_lock_try(window->render_lock);

                // only render if we were able to get the lock
                if (got_lock)
                {
                        render_primitive_list *primlist;

                        mtlog_add("winwindow_video_window_update: got lock");

                        // don't hold the lock; we just used it to see if rendering was still happening
                        osd_lock_release(window->render_lock);

                        // ensure the target bounds are up-to-date, and then get the primitives
                        primlist = (*draw.window_get_primitives)(window);

                        // post a redraw request with the primitive list as a parameter
                        last_update_time = timeGetTime();
                        mtlog_add("winwindow_video_window_update: PostMessage start");
                        if (multithreading_enabled)
                                PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        else
                                SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        mtlog_add("winwindow_video_window_update: PostMessage end");
                }
        }


Linux:

Code: [Select]

                // only render if we have been signalled
                if (osd_event_wait(window->rendered_event, 0))
                {
                        worker_param wp;
                        render_primitive_list *primlist;

                        clear_worker_param(&wp);

                        // ensure the target bounds are up-to-date, and then get the primitives
                        primlist = &window->get_primitives(window);

                        // and redraw now

                        wp.list = primlist;
                        wp.window = window;
                        wp.machine = machine;

                        execute_async(&draw_video_contents_wt, &wp);
                }



[Calamity]

I've attached the logs with the drm debug messages (still with iso 1.269) when running glxgears for a moment, hopefully it will give some info to catch the bug.

I'll need to look more into the code to understand how the osd works and so how your patch is modifying it.

[bitbytebit]

I've attached the logs with the drm debug messages (still with iso 1.269) when running glxgears for a moment, hopefully it will give some info to catch the bug.

I'll need to look more into the code to understand how the osd works and so how your patch is modifying it.

I've figured out the SDL way of doing it, and it works pretty nice, I haven't been able to test it to prove it can go above 100% CPU and use both but suspecting it can.

The Windows side is looking like I may have figured it out, still testing that.  The key in both seems to be the fact they are using the rendering lock and that isn't necessary when using multithreading in the SDL version at all.   In the Windows version that rendering lock is actually Critical section (in SDL it's a mutex from SDL) and so in Windows we actually need to guard our vsync lock with that lock when locking/unlocking the vsync lock.  It also looks like I'll need to use possibly another type of lock than the built in they use for the render_lock, since for some reason it runs but keyboard and input don't work when using it that way.  It's odd, at least it seems to allow -mt and -waitvsync and -nothrottle to all work together the same at least as without the -mt option.  We will see if the threads are actually able to gain performance in this way, or if there's bottle necks possibly from them.

SDL:

Code: [Select]

diff --git a/src/emu/video.c b/src/emu/video.c
index a0720e1..2d152b8 100644
--- a/src/emu/video.c
+++ b/src/emu/video.c
@@ -248,6 +248,10 @@ void video_manager::frame_update(bool debug)
        if (!debug && !skipped_it && effective_throttle())
                update_throttle(current_time);
 
+       // Wait for vsync
+       if (!effective_throttle())
+               m_machine.osd().vsync_wait();
+
        // ask the OSD to update
        g_profiler.start(PROFILER_BLIT);
        m_machine.osd().update(!debug && skipped_it);
diff --git a/src/osd/osdepend.c b/src/osd/osdepend.c
index 110387e..95022ac 100644
--- a/src/osd/osdepend.c
+++ b/src/osd/osdepend.c
@@ -131,6 +131,16 @@ void osd_interface::update_hi(bool skip_redraw)
        //
 }
 
+//-------------------------------------------------
+// Vsync wait
+//-------------------------------------------------
+
+void osd_interface::vsync_wait()
+{
+       //
+       // Wait for vsync to send update
+       //
+}
 
 //-------------------------------------------------
 //  init_debugger - perform debugger-specific
diff --git a/src/osd/osdepend.h b/src/osd/osdepend.h
index 2915286..492da72 100644
--- a/src/osd/osdepend.h
+++ b/src/osd/osdepend.h
@@ -92,6 +92,9 @@ public:
       
        //MKCHAMP - DECLARING THE NEW osd_update_hi SUB
        virtual void update_hi(bool skip_redraw);
+
+       // vsync locking
+       virtual void vsync_wait();
       
 private:
        // internal state
diff --git a/src/osd/sdl/osdsdl.h b/src/osd/sdl/osdsdl.h
index 5b280fc..4ab7ec7 100644
--- a/src/osd/sdl/osdsdl.h
+++ b/src/osd/sdl/osdsdl.h
@@ -145,6 +145,9 @@ public:
        virtual void update(bool skip_redraw);
        virtual void update_hi(bool skip_redraw);
 
+       // vsync wait
+       virtual void vsync_wait();
+
        // debugger overridables
        virtual void init_debugger();
        virtual void wait_for_debugger(device_t &device, bool firststop);
diff --git a/src/osd/sdl/video.c b/src/osd/sdl/video.c
index 32ef4c8..c03a7f4 100644
--- a/src/osd/sdl/video.c
+++ b/src/osd/sdl/video.c
@@ -81,6 +81,7 @@ osd_gl_dispatch *gl_dispatch;
 
 static sdl_monitor_info *primary_monitor;
 static sdl_monitor_info *sdl_monitor_list;
+static int multithreading_enabled;
 
 //============================================================
 //  PROTOTYPES
@@ -326,6 +327,28 @@ sdl_monitor_info *sdlvideo_monitor_from_handle(UINT32 hmonitor)
 
 
 //============================================================
+// vsync_wait
+//============================================================
+void sdl_osd_interface::vsync_wait()
+{
+       sdl_window_info *window;
+
+       if( video_config.perftest || !multithreading_enabled)
+               return;
+
+       if (machine().video().throttled())
+               return;
+
+       for (window = sdl_window_list; window != NULL; window = window->next) {
+               while (!osd_event_wait(window->vsync_wait, osd_ticks_per_second())) {
+                       mame_printf_warning("vsync_wait: osd_event_wait timed out\n");
+               }
+       }
+       return;
+}
+
+
+//============================================================
 //  update
 //============================================================
 
@@ -349,11 +372,17 @@ void sdl_osd_interface::update(bool skip_redraw)
                                 int i;
                                 for (i = 0; i < machine().redraw; i++)
                                 {
+                                       vsync_wait();
                                         sdlwindow_video_window_update(&machine(), window);
                                 }
                         }
                 }
 //      profiler_mark(PROFILER_END);
+       } else if (multithreading_enabled && !machine().video().throttled()) {
+                for (window = sdl_window_list; window != NULL; window = window->next) {
+                       osd_event_set(window->vsync_wait);
+                       mame_printf_warning("update: osd_event_set removing vsync lock\n");
+               }
        }
 
        // poll the joystick values here
@@ -689,6 +718,8 @@ static void extract_video_config(running_machine *machine)
        video_config.restrictonemonitor = !options_get_bool(machine->options(), SDLOPTION_USEALLHEADS);
        #endif
 
+       multithreading_enabled = options_get_bool(machine->options(), SDLOPTION_MULTITHREADING);
+
 
        if (machine->debug_flags & DEBUG_FLAG_OSD_ENABLED)
                video_config.windowed = TRUE;
diff --git a/src/osd/sdl/window.c b/src/osd/sdl/window.c
index 404dd0a..105d044 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -694,6 +694,9 @@ int sdlwindow_video_window_create(running_machine *machine, int index, sdl_monit
        // create an event that we can use to skip blitting
        window->rendered_event = osd_event_alloc(FALSE, TRUE);
 
+       // wait event for vsync before we draw again
+       window->vsync_wait = osd_event_alloc(FALSE, TRUE);
+
        // load the layout
        window->target = machine->render().target_alloc();
 
@@ -788,6 +791,7 @@ static void sdlwindow_video_window_destroy(running_machine *machine, sdl_window_
 
        // free the event
        osd_event_free(window->rendered_event);
+       osd_event_free(window->vsync_wait);
 
        // free the window itself
        global_free(window);
@@ -990,7 +994,7 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                }
 
                // only render if we have been signalled
-               if (osd_event_wait(window->rendered_event, 0))
+               if (multithreading_enabled || osd_event_wait(window->rendered_event, 0))
                {
                        worker_param wp;
                        render_primitive_list *primlist;
@@ -1007,7 +1011,13 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
+               } else if( !video_config.perftest && multithreading_enabled && !machine->video().throttled()) {
+                       osd_event_set(window->vsync_wait);
+                       mame_printf_warning("window_update: osd_event_set removing vsync lock from wait timeout\n");
                }
+       } else if( !video_config.perftest && multithreading_enabled && !machine->video().throttled()) {
+               osd_event_set(window->vsync_wait);
+               mame_printf_warning("window_update: osd_event_set removing vsync lock from target = NULL\n");
        }
 }
 
@@ -1229,8 +1239,13 @@ static OSDWORK_CALLBACK( draw_video_contents_wt )
        {
                if( video_config.perftest )
                        measure_fps(window, dc, update);
-               else
+               else {
                        window->draw(window, dc, update);
+                       if (multithreading_enabled && !wp->machine->video().throttled()) {
+                               osd_event_set(window->vsync_wait);
+                               //mame_printf_warning("draw: osd_event_set removing vsync lock from draw vsync\n");
+                       }
+               }
        }
 
        /* all done, ready for next */
diff --git a/src/osd/sdl/window.h b/src/osd/sdl/window.h
index fe993c6..090ff52 100644
--- a/src/osd/sdl/window.h
+++ b/src/osd/sdl/window.h
@@ -70,6 +70,7 @@ struct _sdl_window_info
 
        // rendering info
        osd_event *                     rendered_event;
+       osd_event *                     vsync_wait;
        render_target *         target;
        render_primitive_list *primlist;


Windows: (currently breaks input)

Code: [Select]

diff --git a/src/osd/windows/video.c b/src/osd/windows/video.c
index e64dfcc..f209f32 100644
--- a/src/osd/windows/video.c
+++ b/src/osd/windows/video.c
@@ -87,7 +87,7 @@ win_video_config video_config;
 // monitor info
 win_monitor_info *win_monitor_list;
 static win_monitor_info *primary_monitor;
-
+static int multithreading_enabled;
 
 
 //============================================================
@@ -207,6 +207,25 @@ win_monitor_info *winvideo_monitor_from_handle(HMONITOR hmonitor)
        return NULL;
 }
 
+//============================================================
+//  vsync_wait
+//============================================================
+
+void windows_osd_interface::vsync_wait()
+{
+       if (machine().video().throttled() || !video_config.waitvsync)
+               return;
+
+       if (!multithreading_enabled)
+               return;
+
+       for (win_window_info *window = win_window_list; window != NULL; window = window->next) {
+               osd_lock_acquire(window->render_lock);
+               osd_lock_acquire(window->vsync_lock);
+               osd_lock_release(window->render_lock);
+       }
+       return;
+}
 
 
 //============================================================
@@ -224,7 +243,7 @@ void windows_osd_interface::update(bool skip_redraw)
         }
 
        // if we're not skipping this redraw, update all windows
-       if (!skip_redraw)
+       if (!skip_redraw) {
                for (win_window_info *window = win_window_list; window != NULL; window = window->next)
                {
                        winwindow_video_window_update(window);
@@ -233,10 +252,19 @@ void windows_osd_interface::update(bool skip_redraw)
                                int i;
                                for (i = 0; i < machine().redraw; i++)
                                {
+                                      vsync_wait();
                                        winwindow_video_window_update(window);
                                }
                        }
                }
+       } else {
+               for (win_window_info *window = win_window_list; window != NULL; window = window->next) {
+                       osd_lock_acquire(window->render_lock);
+                       osd_lock_release(window->vsync_lock);
+                       osd_lock_release(window->render_lock);
+               }
+       }
+               
 
        // poll the joystick values here
        winwindow_process_events(&machine(), TRUE);
@@ -273,7 +301,7 @@ void windows_osd_interface::update_hi(bool skip_redraw)
                                }
                        }
                }
-        }
+        }
 
        // poll the joystick values here
        winwindow_process_events(&machine(), TRUE);
@@ -447,6 +475,8 @@ static void extract_video_config(running_machine *machine)
        video_config.keepaspect    = options_get_bool(machine->options(), WINOPTION_KEEPASPECT);
        video_config.numscreens    = options_get_int(machine->options(), WINOPTION_NUMSCREENS);
 
+       multithreading_enabled = options_get_bool(machine->options(), WINOPTION_MULTITHREADING);
+
        // if we are in debug mode, never go full screen
        if (machine->debug_flags & DEBUG_FLAG_OSD_ENABLED)
                video_config.windowed = TRUE;
diff --git a/src/osd/windows/window.c b/src/osd/windows/window.c
index aac1453..40b38a9 100644
--- a/src/osd/windows/window.c
+++ b/src/osd/windows/window.c
@@ -634,6 +634,7 @@ void winwindow_video_window_create(running_machine *machine, int index, win_moni
 
        // create a lock that we can use to skip blitting
        window->render_lock = osd_lock_alloc();
+       window->vsync_lock = osd_lock_alloc();
 
        // load the layout
        window->target = machine->render().target_alloc();
@@ -704,6 +705,7 @@ static void winwindow_video_window_destroy(win_window_info *window)
 
        // free the lock
        osd_lock_free(window->render_lock);
+       osd_lock_free(window->vsync_lock);
 
        // free the window itself
        global_free(window);
@@ -763,7 +765,9 @@ void winwindow_video_window_update(win_window_info *window)
                mtlog_add("winwindow_video_window_update: try lock");
 
                // only block if we're throttled
-               if (window->machine->video().throttled() || timeGetTime() - last_update_time > 250)
+               if (multithreading_enabled && !window->machine->video().throttled())
+                       got_lock = TRUE;
+               else if (window->machine->video().throttled() || timeGetTime() - last_update_time > 250)
                        osd_lock_acquire(window->render_lock);
                else
                        got_lock = osd_lock_try(window->render_lock);
@@ -776,7 +780,8 @@ void winwindow_video_window_update(win_window_info *window)
                        mtlog_add("winwindow_video_window_update: got lock");
 
                        // don't hold the lock; we just used it to see if rendering was still happening
-                       osd_lock_release(window->render_lock);
+                       if (!multithreading_enabled && window->machine->video().throttled())
+                               osd_lock_release(window->render_lock);
 
                        // ensure the target bounds are up-to-date, and then get the primitives
                        primlist = (*draw.window_get_primitives)(window);
@@ -790,6 +795,10 @@ void winwindow_video_window_update(win_window_info *window)
                                SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
                        mtlog_add("winwindow_video_window_update: PostMessage end");
                }
+       } else {
+               osd_lock_acquire(window->render_lock);
+               osd_lock_release(window->vsync_lock);
+               osd_lock_release(window->render_lock);
        }
 
        mtlog_add("winwindow_video_window_update: end");
@@ -1524,8 +1533,11 @@ static void draw_video_contents(win_window_info *window, HDC dc, int update)
                {
                        (*draw.window_draw)(window, dc, update);
                        mtlog_add("draw_video_contents: drawing finished");
+
+                       osd_lock_release(window->vsync_lock);
+                       mtlog_add("draw_video_contents: vsync lock released");
                }
-       }
+       }
 
        osd_lock_release(window->render_lock);
        mtlog_add("draw_video_contents: render lock released");
diff --git a/src/osd/windows/window.h b/src/osd/windows/window.h
index e8be2ac..9141ffd 100644
--- a/src/osd/windows/window.h
+++ b/src/osd/windows/window.h
@@ -97,6 +97,7 @@ struct _win_window_info
 
        // rendering info
        osd_lock *                      render_lock;
+       osd_lock *                      vsync_lock;
        render_target *         target;
        int                                     targetview;
        int                                     targetorient;
diff --git a/src/osd/windows/winmain.h b/src/osd/windows/winmain.h
index b5f5421..7f6fa77 100644
--- a/src/osd/windows/winmain.h
+++ b/src/osd/windows/winmain.h
@@ -164,6 +164,8 @@ public:
        //MKChamp - Declaring hi subroutine
        virtual void update_hi(bool skip_redraw);
 
+       // wait for vsync
+       virtual void vsync_wait();
 private:
        static void osd_exit(running_machine &machine);