Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Linux scanline position - working prototype  (Read 4621 times)

0 Members and 1 Guest are viewing this topic.

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Linux scanline position - working prototype
« on: January 23, 2019, 10:00:18 am »
Hi Calamity,

How do you expect me to provide the electron beam position under Linux? Shall I mimic the GetRasterStatus call and provide the InVBlank flag and scanline number?

Or do you want the call to drmWaitVBlank to return the position of the beam when triggered?
« Last Edit: January 25, 2019, 04:40:31 am by Doozer »

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - prototyping
« Reply #1 on: January 23, 2019, 04:36:15 pm »

I am getting good results with the scanout position implementation. The kernel side is almost done. I am now looking at a easy way to reuse IOCTL/drm functions to exchange the information with the user space. Next step consists in finding a clever mechanism to share the position with backward compatible behaviour on standard drm wait for vblank.

Here is what the function report as beam positions for each vblank calls made by GM. Measurement is taken at function entry point. GM code was not altered in this run. 

Code: [Select]
[   72.010107] [drm] crtc 0 : hor:293 vert:39
[   72.027184] [drm] crtc 0 : hor:212 vert:38
[   72.044281] [drm] crtc 0 : hor:238 vert:37
[   72.061447] [drm] crtc 0 : hor:286 vert:37
[   72.078658] [drm] crtc 0 : hor:237 vert:38
[   72.095797] [drm] crtc 0 : hor:146 vert:38
[   72.113006] [drm] crtc 0 : hor:90 vert:39
[   72.130094] [drm] crtc 0 : hor:66 vert:38
[   72.147214] [drm] crtc 0 : hor:210 vert:37
[   72.164445] [drm] crtc 0 : hor:270 vert:38
[   72.181534] [drm] crtc 0 : hor:250 vert:37
[   72.198704] [drm] crtc 0 : hor:322 vert:37
[   72.216065] [drm] crtc 0 : hor:55 vert:41
[   72.233398] [drm] crtc 0 : hor:312 vert:43
[   72.250224] [drm] crtc 0 : hor:252 vert:38
[   72.267375] [drm] crtc 0 : hor:223 vert:38
[   72.284543] [drm] crtc 0 : hor:287 vert:38
[   72.301703] [drm] crtc 0 : hor:305 vert:38
[   72.318907] [drm] crtc 0 : hor:222 vert:39
[   72.335977] [drm] crtc 0 : hor:104 vert:38
[   72.353137] [drm] crtc 0 : hor:122 vert:38
[   72.370280] [drm] crtc 0 : hor:50 vert:38
[   72.387532] [drm] crtc 0 : hor:222 vert:39
[   72.404628] [drm] crtc 0 : hor:239 vert:38
[   72.421768] [drm] crtc 0 : hor:154 vert:38
[   72.438921] [drm] crtc 0 : hor:135 vert:38
[   72.456137] [drm] crtc 0 : hor:112 vert:39
[   72.473197] [drm] crtc 0 : hor:276 vert:37
[   72.490541] [drm] crtc 0 : hor:257 vert:40
[   72.507537] [drm] crtc 0 : hor:83 vert:38
[   72.524695] [drm] crtc 0 : hor:96 vert:38
[   72.541904] [drm] crtc 0 : hor:38 vert:39
[   72.558992] [drm] crtc 0 : hor:11 vert:38
[   72.576193] [drm] crtc 0 : hor:246 vert:38
[   72.593285] [drm] crtc 0 : hor:243 vert:37
[   72.610527] [drm] crtc 0 : hor:25 vert:39
[   72.627655] [drm] crtc 0 : hor:209 vert:38
[   72.644777] [drm] crtc 0 : hor:30 vert:38
[   72.662001] [drm] crtc 0 : hor:53 vert:39
[   72.679092] [drm] crtc 0 : hor:41 vert:38
[   72.696250] [drm] crtc 0 : hor:53 vert:38
[   72.713425] [drm] crtc 0 : hor:148 vert:38
[   72.730552] [drm] crtc 0 : hor:332 vert:37
[   72.747740] [drm] crtc 0 : hor:162 vert:38
[   72.764864] [drm] crtc 0 : hor:330 vert:37
[   72.782157] [drm] crtc 0 : hor:38 vert:40
[   72.799203] [drm] crtc 0 : hor:128 vert:38
[   72.816379] [drm] crtc 0 : hor:237 vert:38
[   72.833523] [drm] crtc 0 : hor:170 vert:38
[   72.850706] [drm] crtc 0 : hor:312 vert:38
[   72.867818] [drm] crtc 0 : hor:78 vert:38
[   72.885006] [drm] crtc 0 : hor:244 vert:38

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Linux scanline position - prototyping
« Reply #2 on: January 23, 2019, 04:42:58 pm »
Awesome Doozer!

I understand the "vert" value is the actual scanline, isn't it?

Shall I mimic the GetRasterStatus call and provide the InVBlank flag and scanline number?

Or do you want the call to drmWaitVBlank to return the position of the beam when triggered?

Yes, I'd say it'd be better to have the call return immediately just like GetRasterStatus so we can generalize the wait code for both OSes, possibly using a separate thread and events to communicate with MAME.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - prototyping
« Reply #3 on: January 24, 2019, 01:34:08 am »
Hi,

Yes, the vert value is actually the vertical scanline the beam is drawing.

In parallel I will think about a way to test the accuracy of the positioning.

At the moment I am mainly concentrating on ATI devices but the solution should be fine with other devices as well (nouveau, intel, ...).

The solution (at this stage) will be limited to a single file patch against the kernel.

Best

Envoyé de mon Pixel 3 en utilisant Tapatalk


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Linux scanline position - prototyping
« Reply #4 on: January 24, 2019, 03:40:35 am »
Great!

Also, it'd be nice to be able to poll drm about the availability of the raster feature, so we know whether the kernel is patched or not and apply the correct method accordingly.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - prototyping
« Reply #5 on: January 24, 2019, 05:29:40 am »
Great!

Also, it'd be nice to be able to poll drm about the availability of the raster feature, so we know whether the kernel is patched or not and apply the correct method accordingly.

This feature is indeed part of my roadmap. I will share more about my advancement along with the testing in a near future.

I plan to have GM updated with the proper interfaces and methods (I am not speaking about doing the frame slicing implementation, targetting only the calls from user side). This should permit advancement on your side as well.

I am currently looking at the drm vblank call to perform all the operations (like I described in my PM). If it is working smoothly it will result in a non invasive implementation with 100% backward compatibility for all other application using the DRM library. Lot of testing might be required as well to confirm.



Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - prototyping
« Reply #6 on: January 25, 2019, 04:32:02 am »
I have now scanline position available under GM. The returned value represent the scanline position the beam is drawing. The differentiation is made between active scanline and vblank period using positive and negative value following the description below.

 - Returns sequence as a positive number while in active scanout area.
 - Returns sequence as a negative number inside vblank, counting the number of scanlines to go until end of vblank, e.g., -1 means "one scanline until start of active scanout / end of vblank."

Here are some output from my CORE 2 DUO 8500 cpu with different frame_delay values. Each line is the output right before calling drmWaitVBlank function. You can see in the results that frame_delay 6 is working perfectly and frame_delay 7 is the sweet point to have best lag latency on my system (for this particular game). This is confirmed with the audio being played perfectly until frame_delay 8 is used.

With frame delay 5:
Code: [Select]
SwitchRes: [cninja] (1) horizontal (256x240@58.238857)->(256x240@58.238857)
Current scanout position is 149
Current scanout position is 149
Current scanout position is 150
Current scanout position is 149
Current scanout position is 149
Current scanout position is 149
Current scanout position is 149

With frame delay 6:
Code: [Select]
SwitchRes: [cninja] (1) horizontal (256x240@58.238857)->(256x240@58.238857)
Current scanout position is 175
Current scanout position is 176
Current scanout position is 176
Current scanout position is 176
Current scanout position is 176

With frame delay 7:
Code: [Select]
SwitchRes: [cninja] (1) horizontal (256x240@58.238857)->(256x240@58.238857)
Current scanout position is 206
Current scanout position is 207
Current scanout position is 206
Current scanout position is -57
Current scanout position is 209
Current scanout position is 206

With frame delay 8:
Code: [Select]
SwitchRes: [cninja] (1) horizontal (256x240@58.238857)->(256x240@58.238857)
Current scanout position is -33
Current scanout position is -36
Current scanout position is -35
Current scanout position is -36
Current scanout position is -34
Current scanout position is -36
Current scanout position is -36

With frame delay 9:
Code: [Select]
SwitchRes: [cninja] (1) horizontal (256x240@58.238857)->(256x240@58.238857)
Current scanout position is -8
Current scanout position is -10
Current scanout position is -10
Current scanout position is -10
Current scanout position is -9
Current scanout position is -12
Current scanout position is -12
Current scanout position is -12

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Linux scanline position - working prototype
« Reply #7 on: January 25, 2019, 07:22:15 am »
That's gold!

If I understand you correctly, that's the value reported right before calling to drmWaitVBlank? So that means the cpu clock wait done previously by the frame delay code is very accurate on Linux, considering it lands nearly exactly on the same scanline frame after frame.

In GroovyMAME's Direct3D rendering code is where the calculation of the break scanlines is performed, we should generalize that routine for both OSes.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - working prototype
« Reply #8 on: January 25, 2019, 08:37:11 am »
If I understand you correctly, that's the value reported right before calling to drmWaitVBlank? So that means the cpu clock wait done previously by the frame delay code is very accurate on Linux, considering it lands nearly exactly on the same scanline frame after frame.

This is exactly it. I forgot to mention that measurements were done with an ATI card. Behavior should be the same for at least NVIDIA (nouveau driver),  i915 and amdgpu (would require some testing to confirm this one).

In GroovyMAME's Direct3D rendering code is where the calculation of the break scanlines is performed, we should generalize that routine for both OSes.

Shouldn't the common code portion be exported to a separate class first?


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Linux scanline position - working prototype
« Reply #9 on: January 25, 2019, 05:22:52 pm »
Shouldn't the common code portion be exported to a separate class first?

Yes. We need to build a sync library.
« Last Edit: January 26, 2019, 03:53:48 am by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - working prototype
« Reply #10 on: February 12, 2019, 07:36:32 am »
I do not want to loose the momentum on the subject. I did several Kernel tests and I am fine with the current implementation.

The user side is really simple and does not require too much engineering.

Standard drmvblank structure is used. A unique request type is introduced (0x40) to tell the Kernel to output the scanout position. The sequence parameter must be set to 0 (mandatory at the moment). The scanout position is returned immediately in the reply part of the structure (vbl.reply.sequence).

The call to drmWaitVBlank with type 0x40 returns 0 if the scanout patch is present. This make the code compatible with patched and non patched kernels. Stock kernel will always return a negative value.

The following code outputs the scanline position before every waitvblank call.

Code: [Select]
--- drawogl.cpp_awk_ori 2019-01-14 16:47:34.701281847 +0100
+++ drawogl.cpp 2019-01-25 10:56:09.505507539 +0100
@@ -1413,8 +1413,19 @@
        if (video_config.waitvsync && m_fd)
        {
                drmVBlank vbl;
+               // - Returns sequence as a positive number while in active scanout area.
+               // - Returns sequence as a negative number inside vblank, counting the number of scanlines to go until end of vblank, e.g., -1 means "one scanline until start of active scanout / end of vblank."
                memset(&vbl, 0, sizeof(vbl));
-               vbl.request.type = DRM_VBLANK_RELATIVE;
+               vbl.request.type = (drmVBlankSeqType) 0x40;
+               vbl.request.sequence = 0;
+               int ret = 0;
+               ret=drmWaitVBlank(m_fd, &vbl);
+               if (ret != 0)
+                       osd_printf_verbose("drm get scanout failed, code %d\n", ret);
+               osd_printf_verbose("Current scanout position is %d\n",vbl.reply.sequence);
+
+               memset(&vbl, 0, sizeof(vbl));
+               vbl.request.type = DRM_VBLANK_RELATIVE;
                vbl.request.sequence = 1;
                if (drmWaitVBlank(m_fd, &vbl) != 0)
                        osd_printf_verbose("drmWaitVBlank failed\n");

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Linux scanline position - working prototype
« Reply #11 on: February 12, 2019, 12:24:02 pm »
Hi Doozer,

That's great! I'm in the process of implementing the Windows side using D3DKMTGetScanLine, not sure if it'll be ready for 0.207 but I'd like to start making the common library that shares the same logic between Windows and Linux.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - working prototype
« Reply #12 on: February 12, 2019, 01:21:06 pm »
Hi Doozer,

That's great! I'm in the process of implementing the Windows side using D3DKMTGetScanLine, not sure if it'll be ready for 0.207 but I'd like to start making the common library that shares the same logic between Windows and Linux.

Wonderful! The community can really be thankful for the energy you spend in this project.

Feel free to share via PM or email parts you want to be tested or fine tuned. One possibility would be to encapsulate the call to the D3D GetScanLine and drmWaitVBlank codes into a function inside the respective osd library. But I assume you have already thought about it.

I am wondering if I should put the kernel patches (15Khz, interlace fix, scanout) on a git repository and maintain them or perhaps just drop them on a google drive. I am always tracking and compiling them against each individual stable kernel releases anyway.


donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 07:37:50 pm
  • I want to build my own arcade controls!
Re: Linux scanline position - working prototype
« Reply #13 on: February 13, 2019, 05:09:24 am »
This thread should be pinned.

Very interesting and important development here.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: Linux scanline position - working prototype
« Reply #14 on: February 13, 2019, 06:17:00 am »
Is this what will allow auto frame_delay/vsync_offset ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Linux scanline position - working prototype
« Reply #15 on: February 13, 2019, 06:39:10 am »
Is this what will allow auto frame_delay/vsync_offset ?

It's a necessary but not sufficient condition.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Trnzaddict

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 175
  • Last login:September 24, 2023, 12:12:29 pm
Re: Linux scanline position - working prototype
« Reply #16 on: February 14, 2019, 06:57:10 am »
Is this goal of beam racing more Input Lag reduction?

If so how much can we expect to shave off?

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: Linux scanline position - working prototype
« Reply #17 on: March 09, 2019, 12:48:36 pm »
Indeed, this effort will allow better accuracy and help triggering the input processing more precisely. Both Windows and Linux versions will be greatly enhanced with a platform agnostic implementation. Still, it is too early to give details or statics about gain to be expected.