Members 
Search 
Help 
Register 
Login 
Home Show: Today's Messages :: Show Polls :: Message Navigator
|
   |
| Xv rendering support needed for laptops with SM712 video [message #1404] | Sun, 01 February 2009 06:07  |
||||
| |||||
|
The SM7XX-series behaves incredibly badly with Mednafen. This is bad, because a lot of UMPCs are going back to using this card because of its incredibly low power requirements. The new Lemote Yeeloong ships with this card. The Linux driver creates one Xv port, but the card lacks 3D accelerations so there is no OpenGL layer. SDL is the root of the problem, because SDL is not attaching itself to the Xv port instead choosing software rendering. The Loongson is quite powerful, and even at low clockspeeds can manage 2x scaling in software on the Wonderswan. There's virtually no difference between filtered and unfiltered output, because the bottleneck is the rendering. Is there any chance of getting Xv support into Mednafen? It would basically solve this problem and allow for fullscreen scaling, which is currently impossible. The card won't support resolutions as low as 320x240, so any display has to be scaled 2x or more. With FC ROMs, this leads to extreme stuttering. I mentioned this to byuu, and he said he would be interested in helping you get Xv rendering support while using SDL for gamepad input, since that's how he does it in bsnes. If adding Xv is out of the question though, well, at least the games all run full speed, just can't scale them  Here are some pictures with screenshots of various systems running in mednafen with their frameskips shown. These were taken from a profiled build of 0.8.a on a Loongson 2F@797MHz. I did not try it in an overclocked state: http://s153.photobucket.com/albums/s223/dsobodash/Lemote%20Yeeloong/Emulation%20Test/ | |||||
| |||||
| Re: Xv rendering support needed for laptops with SM712 video [message #1408 is a reply to message #1404 ] | Sun, 01 February 2009 15:25  |
|||
| ||||
Do you know if the Loongson implementation of MIPS has SIMD instructions? I really don't know much about MIPS in general... The NES/FC sound resampling code is going to be a bottleneck on...everything other than x86/x86_64 MMX, come to think of it. :b
Does SDL support Xv through its "overlays"? Or does byuu use Xv directly? I'm guessing Xv doesn't allow for video frames that have multiple source widths at different points(vertical) on the screen? 3(maybe more?) PC Engine games change resolutions mid-frame, though I could always have an optimized software scaler for those. | ||||
| ||||
| Re: Xv rendering support needed for laptops with SM712 video [message #1409 is a reply to message #1408 ] | Sun, 01 February 2009 23:23 |
||||
| |||||
|
You may want to take a look at some of the info docs on the Loongson 2F. STMicroelectronics has a PDF at http://www.st.com/stonline/products/literature/bd/13577.pdf It does have one 64-bit streaming multimedia instruction set (SIMD). I believe byuu does Xv directly, using xinput for keyboard presses and SDL for a gamepad hook. He may be in a different position though since his display is running inside Gtk while your's directly creates an SDL/GL window, so maybe you wouldn't need to bother with xinput. That would answer why FC runs so sadistically slow whereas Wonderswan performs great even at 2x software scaling. Fast kernel timer frequencies (up to 1024Hz) don't seem to make a significant difference in mednafen's performance. [Updated on: Sun, 01 February 2009 23:24] | |||||
| |||||
| Re: Xv rendering support needed for laptops with SM712 video [message #1418 is a reply to message #1408 ] | Mon, 09 February 2009 02:25 |
||||
| |||||
|
Update" byuu and I tested bsnes on the Loongson using his SDL and Xv drivers. It does indeed solve the problem, with Xv allowing double and triple scaling with no drop in framerate where SDL collapses. Hi, sorry about the delay in answering your AIM message (why are you never on anymore ...?)
d@medan:~$ cat /proc/cpuinfo
system type : lemote-notebook
processor : 0
cpu model : ICT Loongson-2 V0.3 FPU V0.1
BogoMIPS : 522.24
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
d@medan:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
199245 298867 398490 498112 597735 697357 796980
d@medan:~$ dmesg | grep display
Silicon Motion display driver version 0.11.2619.21.01 July 27, 2008
Silicon Motion SM712 RevB0 primary display mode 1024x600-16 Init Complete.
d@medan:~$ cat /var/log/Xorg.0.log | grep Silicon
(--) PCI:*(0:8:0) Silicon Motion, Inc. SM712 LynxEM+ rev 176, Mem @ 0x50000000/24
(II) Silicon Motion: driver (version 2.2.8) for Silicon Motion Lynx chipsets:
(**) Silicon MotionDepth 16, (--) framebuffer bpp 16
(==) Silicon MotionRGB weight 565
(==) Silicon MotionDefault visual is TrueColor
(**) Silicon MotionOption "pci_burst" "true"
(**) Silicon MotionOption "HWCursor" "False"
(**) Silicon MotionOption "UseBIOS" "False"
(**) Silicon MotionOption: pci_burst - PCI burst read enabled
(**) Silicon MotionUsing Software Cursor
(**) Silicon MotionOption: UseBIOS disabled.
(II) Silicon MotionNo legacy BIOS found -- trying PCI
(EE) Silicon MotionCannot read V_BIOS (5)
(--) Silicon MotionChipset: "LynxEM+"
(II) Silicon MotionOFF Panel Size = 0x0
(II) Silicon Motion SiliconMotion Driver
(II) Silicon MotionvgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) Silicon MotionI2C bus "I2C bus" initialized.
(--) Silicon MotionNo DDC signal
(II) Silicon MotionI2C device "I2C bus:ddc2" registered at address 0xA0.
(II) Silicon MotionI2C device "I2C bus:ddc2" removed.
(==) Silicon MotionUsing gamma correction (1.0, 1.0, 1.0)
(--) Silicon MotionDetected current MCLK value of 157.500 MHz
(II) Silicon MotionpScrn->virtualX is 0, pScrn->display->virtualX is 0
(II) Silicon MotionMonitor0: Using hsync range of 30.00-70.00 kHz
(II) Silicon MotionMonitor0: Using vrefresh range of 50.00-80.00 Hz
(II) Silicon MotionClock range: 12.00 to 270.00 MHz
(==) Silicon MotionDPI set to (96, 96)
(II) Silicon MotionPCI: command is 0x7, line 1593
(II) Silicon Motion0:8:0 : value of offset 0x4 is 0x7
(II) Silicon MotionBelcon: myNum is 0
(II) Silicon MotionOFF Panel Size = 1024x600
(II) Silicon Motion SiliconMotion Driver
(II) Silicon MotionvgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) Silicon Motion FBbase is 0x2b6d8000, videoRAMBytes is 0x400000
(II) Silicon Motion SMI_ScreenInit(), nHertz is 60.044312
(EE) Silicon MotionlcdWidth = 1024
(EE) Silicon MotionlcdWidth = 1024 HDisplay = 1024
(II) Silicon MotionHDisplay 1024, VDisplay 600
(II) Silicon MotionpanelIndex = 2 modeIndex = 3
(EE) Silicon MotionRefresh Rate 60.044312Hz , index is 0
(II) Silicon MotionDEBUG:SMI_ModeInit 3681
(II) Silicon Motion Restore mode 0x00
(II) Silicon Motion Mode Pclock 0x0D 0x82
(II) Silicon Motion Alert: SEQ6C is 0x0D, SEQ6D is 0x82
(II) Silicon MotionpSmi->FBOffset is 0x0, x is 0, y is 0
(II) Silicon MotionFrameBuffer Box: 0,0 - 1024,2047
(II) Silicon MotionUsing XFree86 Acceleration Architecture (XAA)
(II) Silicon MotionI2C device "I2C bus:SAA 7111A" registered at address 0x48.
(II) Silicon MotionI2C device "I2C bus:SAA 7111A" removed.
d@medan:~$ xvinfo
X-Video Extension version 2.2
screen #0
Adaptor #0: "Silicon Motion Lynx Series Video Engine"
number of ports: 1
port base: 60
operations supported: PutImage
supported visuals:
depth 16, visualID 0x22
depth 16, visualID 0x23
depth 16, visualID 0x24
depth 16, visualID 0x25
number of attributes: 2
"XV_BRIGHTNESS" (range 0 to 255)
client settable attribute
client gettable attribute (current value is 0)
"XV_COLORKEY" (range 0 to 16777215)
client settable attribute
client gettable attribute (current value is 66051)
number of encodings: 18
encoding ID #0: "pal-composite-0"
size: 704 x 576
rate: 0.020000
encoding ID #1: "ntsc-composite-0"
size: 704 x 480
rate: 0.016683
encoding ID #2: "secam-composite-0"
size: 7040 x 576
rate: 0.020000
encoding ID #3: "pal-composite-1"
size: 704 x 576
rate: 0.020000
encoding ID #4: "ntsc-composite-1"
size: 704 x 480
rate: 0.016683
encoding ID #5: "secam-composite-1"
size: 7040 x 576
rate: 0.020000
encoding ID #6: "pal-composite-2"
size: 704 x 576
rate: 0.020000
encoding ID #7: "ntsc-composite-2"
size: 704 x 480
rate: 0.016683
encoding ID #8: "secam-composite-2"
size: 7040 x 576
rate: 0.020000
encoding ID #9: "pal-composite-3"
size: 704 x 576
rate: 0.020000
encoding ID #10: "ntsc-composite-3"
size: 704 x 480
rate: 0.016683
encoding ID #11: "secam-composite-3"
size: 7040 x 576
rate: 0.020000
encoding ID #12: "pal-svideo-0"
size: 704 x 576
rate: 0.020000
encoding ID #13: "ntsc-svideo-0"
size: 704 x 480
rate: 0.016683
encoding ID #14: "secam-svideo-0"
size: 7040 x 576
rate: 0.020000
encoding ID #15: "pal-svideo-1"
size: 704 x 576
rate: 0.020000
encoding ID #16: "ntsc-svideo-1"
size: 704 x 480
rate: 0.016683
encoding ID #17: "secam-svideo-1"
size: 7040 x 576
rate: 0.020000
[Updated on: Tue, 10 February 2009 11:52] | |||||
| |||||
| Re: Xv rendering support needed for laptops with SM712 video [message #1424 is a reply to message #1418 ] | Fri, 13 February 2009 02:17 |
||||
| |||||
|
Hello, nice to meet you. You have a wonderful program here, keep up the good work! :D If you want to add an Xv driver, I'll be happy to help in any way I can.
I use Xv directly. If I recall (eg you may want to verify), SDL's overlays are completely unable to do any kind of hardware scaling, making it kind of pointless to use. The basic problem is that SDL likes to own the window for video and keyboard / mouse input. No good for me, as I want a menubar and such in my main window. Setting SDL_WINDOWID=handle, where handle is a raw child Xlib Window handle, works well enough. But I imagine you don't want to write your own window creation code for Linux, so we can use another trick of mine that I came up with for when there are no GLX / Xv visuals to match the main window's visual: The idea is to get the raw Xlib handle for your main window (use SDL's WM hint functions), and then use the Xlib API to create a new child window and embed it right inside your main window. Now you can use the raw Xv API to blit to your child window. Since it's opaque, it will obscure SDL's output and stop it from interfering with your custom video data. It's easier than it sounds, you just have to know the API calls involved. Best part is you can put all the messy code right inside your Xv driver. Child window creation: colormap = XCreateColormap(display, parentwindow, visualinfo->visual, AllocNone);
XSetWindowAttributes attributes;
attributes.colormap = colormap;
attributes.border_pixel = 0;
attributes.event_mask = StructureNotifyMask;
xwindow = XCreateWindow(display, /* parent = */ parentwindow,
/* x = */ 0, /* y = */ 0, window_attributes.width, window_attributes.height,
/* border_width = */ 0, xv_depth, InputOutput, visualinfo->visual,
CWColormap | CWBorderPixel | CWEventMask, &attributes);
XFree(visualinfo);
XSetWindowBackground(display, xwindow, /* color = */ 0);
XMapWindow(display, xwindow);If you want to totally abstract the Xv driver to work with any app as I do, you'll need to detect size changes to the parent window, preferably inside the blit() function. Resize sync: XWindowAttributes parent;
XGetWindowAttributes(display, parentwindow, &parent);
if(target.width != parent.width || target.height != parent.height) {
XResizeWindow(display, xwindow, parent.width, parent.height);
}
//update target width and height attributes
XGetWindowAttributes(display, xwindow, &target);You could avoid the need for this by calling a manual resize whenever you resize the main SDL window, of course. ----- There's a lot of tricky problems with supporting Xv, as well. Many drivers give you bad information, most only support YUV colorspace, etc. It gets really detailed, so I'll wait to see if you're still interested before I navigate you through the minefield that is Xv ;) Or if you wanted to go a different route, my API wrappers are basically similar to SDL, but more tailored to emulator usage with automatic hardware scaling where possible. I have drivers for: DirectDraw, Direct3D, OpenGL/Win, GDI, SDL, OpenGL/Linux, X-Video, DirectSound, ALSA, OpenAL, pulseaudio, OSS, DirectInput, SDL and Xlib input. All are abstracted to base Video / Audio / Input classes with 2-6 functions each. Video is as easy as: video.set(Video::Handle, parentwindow_xlibwindow_or_hwnd); video.init(); video.lock(buffer, pitch); //draw to buffer here video.unlock(); video.redraw(width, height); //this is your source width, it scales to fit the size of parentwindow automatically Might be easier to use my API than write your own driver. Assuming you're interested, it'd probably be best to discuss this further through AIM or something.
Nope. Wasn't aware software SDL could do that, either. The SNES does the same thing: the width can be changed every scanline, and the height every frame. Thus, it's not a good idea to do it with OpenGL, as you can end up with up to ~480 hardware draw operations per frame in the absolute worst case scenario. I know -- real games will only do it once or twice, but I like not having deadly edge cases like that :/ I just keep a list of widths for each line, and if it mixes widths, I software-scale each one up before blitting. Only need one buffer due to some magic with the pitch value. ----- Side note, if you ever decide to work on SNES support, please get in touch :) I imagine bsnes is way too slow, but I also know how unfriendly ZSNES / Snes9X can be. I've been planning to make a fast SNES emulator for a while now, could be a good opportunity for discussion. For both Xv and the emu, I'm only offering in case you're personally interested. I don't mean to imply that I'm requesting you do any of this stuff if you don't want to, of course :) | |||||
| |||||
| |
| Previous Topic: | Collaboration for the PC-Engine emulation |
| Next Topic: | question for developers of mednafen |
]
