Rendering performance is weird on Linux: everything depends on "wrong" VU settings

[v-fox]

I've been trying to figure out best settings for my setup and stumbled on really-really weird behaviour. My system is:

Machine:   Mobo: Gigabyte model: GA-990XA-UD3 Bios: Award v: F14e date: 09/09/2014
CPU:       Hexa core AMD FX-6100 Six-Core (-MCP-) speed: 4026 MHz (max)
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Barts XT [Radeon HD 6870]
           Display Server: X.Org 1.17.2 driver: radeon Resolution: 1920x1080@60.00hz
           GLX Renderer: Gallium 0.4 on AMD BARTS GLX Version: 3.0 Mesa 10.6.1

Distro is modified openSUSE 13.2 with latest upstream releases of kernel and graphic stack running glamor 2D acceleration and compton without vsync for some reason (the next driver & Mesa releases should bring 'TearFree' option for hardware vsync control which works even with glamor). pcsx2 build is this. Games used for testing are: SCUS_974.72;1 "Shadow of the Colossus" and SLES_820.42;1 "MGS3: Subsistence"

pcsx2's GSdx says:

glX-Version 1.4 with Direct Rendering
OpenGL information. GPU: Gallium 0.4 on AMD BARTS. Vendor: X.Org
Buggy driver detected. Geometry shaders will be disabled
Buggy driver detected, GL_ARB_separate_shader_objects will be disabled

INFO: GL_EXT_texture_filter_anisotropic is available
INFO: GL_ARB_gpu_shader5 is NOT SUPPORTED
INFO: GL_ARB_draw_buffers_blend is available
INFO: GL_ARB_separate_shader_objects is NOT SUPPORTED
INFO: GL_ARB_shader_subroutine is NOT SUPPORTED
INFO: GL_ARB_shader_image_load_store is NOT SUPPORTED
INFO: GL_ARB_explicit_uniform_location is available
INFO: GL_ARB_copy_image is NOT SUPPORTED
INFO: GL_ARB_buffer_storage is available
INFO: GL_ARB_bindless_texture is NOT SUPPORTED
INFO: GL_ARB_clear_texture is NOT SUPPORTED
INFO: GL_ARB_clip_control is available
INFO: GL_ARB_direct_state_access is available
INFO: GL_ARB_texture_barrier is available

Even thought I'm not sure what's so "buggy" about it.

So, the thing is that pcsx2 can be even remotely useful only if VU settings are exact opposite from "recommended": "VU Cycle Stealing" on max; "mVU Flag Hack" is off; "MTVU" is off.

Everything else is either insignificant or has no bearing on performance whatsoever. Even changing internal resolution from "native" to 3 has almost no discernable FPS difference while picture quality is staggering. Disabling "Accurate X" settings gives very slight FPS boost for the price of missing effects, it seems. There is also pretty much no difference in FPS between OpenGL HW with 3x resolution and SW mode with 3 threads. Both are just 5-15 FPS shy from nominal 50/60 on non-empty scenes depending on their intensity. And at that time CPU load is no more than a third total, smashed over all cores.

So, my point is that on Linux build of pcsx2 graphical performance seems to be dependant not on graphics but on something else entirely, something in VU code. Something that severely underutilizes the system. Which shouldn't be surprising for the only known open project in the universe hardcoded for 32bit legacy support in CPUs.

[refractionpcsx2]

Your performance is bad because your driver isn't very good for OpenGL (hence the buggy driver stuff) so you are missing out on some key features which make it quick. By putting VU Cycle Stealing on full you are probably skipping a lot of frames which will make it seem to run quicker, the other two settings shouldn't make much of a difference to you though.

and 32bit support is only "hardcoded" because we generate our own cpu code with the program depending on the game, so we have to currently

[v-fox]

Your performance is bad because your driver isn't very good for OpenGL (hence the buggy driver stuff)

My driver is supergood ! And it's good for everything, it even natively supports DirectX 9. Believe me, I recently (few months back) compared latest binary one and the open one (not with PCSX2 since the build I had then died on binary driver completely) which, while missing some extensions and OpenCL 1.2 compliance, is made by AMD employees with focus on maximum stability and features. Real features, not some half-baked hacky segfaulting mess to workaround deficiencies of an OS like in the binary one.

What is the definition of that "bugginess" and was it relayed to Mesa developers ? From what I know, they are planning on jumping on 4.X compliance in the near release. Which version of 4.X will it be is not yet certain, probably 2.

I would suggest to be careful with blacklists and seldom definitions of driver quality, especially in your case. Recently latest Firefox was whining about OpenGL acceleration being too "experimental", EGL "unnecessary" and Mesa drivers "too buggy" but after being forced to disabled all the blacklists by undocumented switches it started to work as damn expected from it. I planning on making an installable openSUSE livecd soon with latest graphical stack, that Firefox, DX9-enabled wine and 32bit pcsx2 (along with ppsspp, dolphin and such) so anyone could test out what's buggy or not.

you are probably skipping a lot of frames which will make it seem to run quicker

That would explain choppy cutscenes. So, it does skip frames despite settings window of pcsx2 saying that is impossible, huh ? MTVU takes away 15-20 frames thought and mVU Flag Hack 5-10 more. But again, if frame skipping is happening and FPS counter is false, maybe they really don't.

32bit support is only "hardcoded" because we generate our own cpu code with the program depending on the game

It's just baffling how you the only ones who do that and when actual 32bit CPUs are not even sold anymore. And if you add other weirdness like unexplainable input problems and CPU&GPU extreme underutilization (i just checked: radeontop shows ~25% GPU utilization while a game runs on half nominal FPS) that doesn't look good. But whatever, to my surprise sound works pretty much perfect now, from what I've seen, even with native JACK support ! And build system is not a mess anymore. So, maybe some day... it can be used.

[gregory38]

It's just baffling how you the only ones who do that and when actual 32bit CPUs are not even sold anymore. And if you add other weirdness like unexplainable input problems and CPU&GPU extreme underutilization that doesn't look good.

... Seriously ... Don't be disrespectful ! You're free to use any other emulators.

Mesa is not perfect neither finish. You're the only one here with preconceived idea. Some features are marked buggy because they don't work on Mesa (likely a driver bug but it could be from us). You can control the OpenGL extension from the GUI, so please enable them and check yourself the status.

Mesa is slow and CPU limited, end of the rant. Proof here http://www.phoronix.com/scan.php?page=article&item=amd-7870k-drivers&num=1

[v-fox]

... Seriously ... Don't be disrespectful ! You're free to use any other emulators.

You people seem to like to talk mad shit about Mesa and Linux, so let me talk some mad shit of my own.

Is it not true ? You can name one other F/OSS software that does that ? And don't give me that tantrum: "only we bother to do anything about that, so eat what you get and be grateful for any scraps". Being the only one in what you do doesn't automatically make you infallible. Learn to take critisism for your sloppiness. And the fact that you sick of people complaining about your 32bit obsession and pcsx2 impracticality doesn't change anything.

Now, about Mesa: 1) You linked article about "radeonsi", hardware support of which is incomplete unlike my "radeon" card, accidentally being the model 6870 which is the best supported. From what I've heard, all shader workings of that generation and up are tied to LLVM, completely reimplemented and still unfinished, unlike mine which are based on well tested and polished codepaths. And even if it would be the same: it's comparing pineapples to plain apples. Did you specifically test pcsx2 against both ? I can't because binary radeon driver is a mess which will screw up the system but I will try Windows version on DX & OGL against Linux on Mesa later. 2) "Don't work" ? And what is your testing methodology, which builds and version did you check ? How often do you recheck ? Where are your bug reports and mail logs to Mesa team ? Do you even test pcsx2 on Mesa to say that it's Mesa what is broken and not vendor-specific implementation that you rely upon ? 3) Forcing geometry shaders changes nothing (no picture or FPS difference), forcing GL_ARB_separate_shader_objects garbles picture into lines and squares. I'm sure Mesa devs would love to know what is wrong with that. They even have automated implementation testing kit with a test for every feature that they add.

Don't tell me that my high-end 2010 card can't handle PS2 graphics while even inefficient usage of it barely scratches 50% load. I rechecked enabled MTVU with disabled "VU Cycle Stealing": still ~20-30% FPS drop in any case instead of increase. And apparently, as was revealed above, pcsx2 can skip frames despite what its UI says.

env GALLIUM_HUD="cpu0,cpu1,cpu2,cpu3,cpu4,cpu5;primitives-generated+clipper-primitives-generated,draw-calls,buffer-wait-time,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,GPU-load;.x1000.c100fps" PCSX2

If Mesa is "CPU-limited", what the hell limits pcsx2 ? It's certainly not the CPU and not the GPU. To blame the system you need to make sure that your code that it's running is nothing short of exemplary.

PS: While making tests for this I stumbled upon another inexplicable bug: if pcsx2 crashes on GSdx plugin initialization showing its "Assertion Failed" window then keyboard repeat gets disabled until I relogin or return it with xset r. What's the connection I have no idea, but that's another very weird and unexpected behaviour, same as this whole VU stuff (and a gamepad thing too). Ah, and it also seems to leak VRAM on GS reinit without complete pcsx2 restart. I really hope that Mesa developers are getting detailed reports about its bottlenecks and straight up errors from you.

[ssakash]

And don't give me that tantrum: "only we bother to do anything about that, so eat what you get and be grateful for any scraps". Being the only one in what you do doesn't automatically make you infallible. Learn to take critisism for your sloppiness. And the fact that you sick of people complaining about your 32bit obsession and pcsx2 impracticality doesn't change anything.

Honestly, constructive criticisms are accepted but don't need to be ungracious. also, a large user base of PCSX2 is on 32 bits so discarding them and moving on to 64bits isn't really the wise approach compatibility wise for users. decisions like these needs to be taken after a lot of time and thoughts.

also, I hope you could speak in a better manner in the future. Thanks ;)

[refractionpcsx2]

@v-fox personally, after your attitude like you are paying for our services and we "owe" you something and basically talking to us like we're a completely retarded company outsourcing our call centers to people who don't have a clue how our software works, you will be lucky if anybody here even cares what you think any more.

You could have come here, said something is up as this is happening which isn't right, needs looking in to, but no you basically went "this is happening, your software is shit, sort it out"

That is not constructive criticism and developers, especially of FREE software that we do as a HOBBY, are not gonna take your crap.

So I will grace you with the same level of kindness as you have shown us:

Please, fuck off.

[v-fox]

Honestly, constructive criticisms are accepted but don't need to be ungracious. also, a large user base of PCSX2 is on 32 bits so discarding them and moving on to 64bits isn't really the wise approach compatibility wise for users. decisions like these needs to be taken after a lot of time and thoughts.

Yeah-yeah, "It's easier to put hardware imitation into all modern processors & duplicate all basic software frameworks for it than to force devs who do not abide by coding standards to get their shit together". I've read it a hundred times for the last like 5 years already >_<

You do realise that the most of each of my posts was about PCSX2 team shittalking Mesa, right ? And yet it always goes full defensive on 32bit issue. Well, you right about one thing: it's the least of pcsx'2s problems. If only you people would answer so eagerly about #414

also, I hope you could speak in a better manner in the future. Thanks ;)

I hope you will send those reports to Mesa team detailing specific inadequacies in implementation of each GPU operation that pcsx2 utilises. Seriously. But thanks for being the most patient so far.

You could have come here, said something is up as this is happening which isn't right, needs looking in to, but no you basically went "this is happening, your software is shit, sort it out"

After all these years of the same excuses and the same finger pointing on your side I launch pcsx2 and there is at least a few baffling or completely broken things in pretty much every subsystem: rendering, actual emulation, inputs, UI. I don't know where to begin. And it seems like you either ignore these things, that are sitting right in the face before even title screen is rendered, or just never even test, compare or benchmark anything.

You could have come here, said something is up as this is happening which isn't right, needs looking in to

And I did start it about MTVU severely decreasing performance in all situations (which it does) and all those hacks generally working backwards but then you had to blame Mesa and turn all defensive about one line concerning your old retrogradatory pet peeve.

Please, fuck off.

You all been saying that to all disgruntled users for years with your «don't like it, go elsewhere ! oh, what's that ? there is no elsewhere ? well, then you will have to stroke our egos or shut up» attitude. So, it's your turn now.

There's the picture showing quite a slowdown while GPU and CPU are barely active. I would even bet that the load that is detected is far from being entirely useful (akin to glxgears and other tools that just burn cycles). So, explain to me, how exactly is this Mesa's fault ? Or better yet, explain to those who actually get payed for fixing Mesa. Test and stabilise your goddamn changes and when they will be stellar, you may blame someone else, with links on your ignored reports about "buggy drivers".

[refractionpcsx2]

I'd love to discuss things with Mesa about the problems we seem to be having with their drivers (and we refer to it as buggy driver because it works fine with other drivers, hence there is a bug somewhere, we do this so we can continue to make it work on those drivers avoiding the problem temporarily), however that is not my place as I do not deal with that. I know gregory DOES contact the developers, he has had things fixed by AMD due to him reporting back to them about issues, i expect he probably does the same with Mesa, however you are quick to jump to the conclusion because we haven't done something publicly that we aren't doing it and that deserves your outrage thrown at us? That's very narrow minded and subjective of you.

If you are so convinced it is our problem and not theirs going from your huge defensiveness of the Mesa guys, you are more than welcome to fix the problem as you seem to know it stems from our side, we have obviously missed it, but this is an open source project so other people including you can contribute to it and make it better. The same goes for all those other problems you noticed, however I think you seem to completely underestimate what a difficult task emulating the playstation 2 is, like we're just being thick idiots causing it not to work, not because this is actually a challenge or anything.

[gregory38]

Mesa devs are well aware that Mesa has limitation, you can check any article from phoronix. I didn't send a bug report because it isn't important and potentially the issue is in our code. An issue is open on this bug tracker.

[v-fox]

I know gregory DOES contact the developers, he has had things fixed by AMD due to him reporting back to them about issues, i expect he probably does the same with Mesa

Well, that's something beneficial and productive for everyone.

however you are quick to jump to the conclusion because we haven't done something publicly that we aren't doing it and that deserves your outrage thrown at us? That's very narrow minded and subjective of you.

The fact is that Mesa puts stability and consistency above performance and speed of implementing half-baked features. It may as well be reference implementation of OpenGL standards (which, by the way, were in making about the same length of time as pcsx2 and by entirely non-paid devs until recently). PCSX2 is complete antithesis of that. And then the damn thing does something like what's on that picture, or like breaking keyboard repeat for entire user session, or ignoring half of gamepad buttons, or not showing a config window, or segfaulting, or... being hardcoded for single and obsolete architecture (while Mesa even runs on Windows... I don't know why but it damn does), you're not the ones to call something like that "buggy". You not the ones to call something that may be a reference implementation of OpenGL "isn't very good for OpenGL", effectively calling it impractical for its purpose. Because there is something else that is more impractical.

If you are so convinced it is our problem and not theirs going from your huge defensiveness of the Mesa guys

Again, if you are so sure that its their problem then you probably have made tests clearly indicating that... and shown those to them, right ? And you can show them to me, right ? Because they do have infinitely better track record than you. While they did start out with nothing, hopelessly featureless, lagged, unmaintained, bare entusiasm-supported code, too.

No, I believe that it may perform better on the system that you have and usage pattern that you perform. But not necessary because they are better. What if you hardcoded something for that particular system and pattern ? What if you relied on working around that system's bugs and poor design choices which introduced bugs and poor design choices of your own ?

I don't know. But it just doesn't look good. You know what happened when I've built the latest "release" of PCSX2 before I build the latest revision ? Black screen with counters on top struggling to count those black frames. But not on latest revision, now it's working somehow (GSdx-only, why zzogl is even built I have no idea). What kind of release is that ?

I'm planning on making a livecd release with all the best console emulators for Linux for each system that there are (that's not many: mednafen, openmsx, ppsspp, pcsx-r, pcsx2, dolphin, desmume, mupen64plus and yabause) and latest kernel & Mesa-only, as I've mentioned. And for that I'm testing each of them. And each of them, even the most pathetically looking one (but also unique), yabause, have managed map the damn buttons on the damn gamepad (some of them did try map axises instead of buttons thought, which had to be manually changed). But not pcsx2, with all its fancy stuff and several input plugins made specifically for DualShock inputs. And then there's that:

env GALLIUM_HUD="cpu0,cpu1,cpu2,cpu3,cpu4,cpu5;.x1600primitives-generated+clipper-primitives-generated,draw-calls,buffer-wait-time,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,GPU-load;.x835.c100fps" dolphin-emu

For some reason it dynamically changes FPS cap between 24,30,50,60,etc. but judging by this load I pretty sure it can handle up to 100. It's in 2x resolution too. Same hardware and software (all-Mesa), measured after the previous picture.

however I think you seem to completely underestimate what a difficult task emulating the playstation 2 is, like we're just being thick idiots causing it not to work, not because this is actually a challenge or anything.

Oh, I think that it's almost impossible and you're nuts for trying. But I respect that, the daringness. That's cool. If you're finishing your glitchy code before blaming somebody else's non-glitching, and one of the stablest and most reliable there is, as unfinished, buggy or whatever. Same goes for motherfuckers from modern Mozilla but that's an even longer and more colourful story.

Mesa devs are well aware that Mesa has limitation it isn't important and potentially the issue is in our code

If it is as bad as you make out it to be, then it sounds pretty important. But whatever. Before PCSX2 goes bottlenecking on GPU driver limitations I really would like to see it using CPU at its fullest in a consistent way at least. Now, as I've said, MTVU doesn't seem to even load CPU any more but slows things down and the rest EE/VU things are just weird.

[bositman]

Thanks but we are very much full of self righteous internet trolls that demand stuff from us because their e-ego is off the roof.

Yes this is a free software and yes we have every right to tell you if you don't like it don't use it. Of course we don't with most of our users, you can check how many people get help daily on our support forum for years.

Everyone fixes what they can, when they can and if they want to. We are all volunteers and our only goal is to make this program better, not to 'stroke our egos' or tell people to fuck off. You are making it very hard not to say that though. If you want something fixed, make a proper bug report. If you want to rant, flame, accuse or 'show them who's boss' you're in the wrong place and need to grow up.

[v-fox]

If you want something fixed, make a proper bug report.

A-huh, right. Just ignore every point I've made and every technicality I've shown to continue your "we do what we like, and we say what we like, and we ignore what we don't like" rant. Answer for your own damn code and stop making excuses.

Again, 1) Any "speedup" with all EE/VU hacks seems to be a straight up lie for frameskipping that is supposedly "impossible". MTVU doesn't seem to load CPU any more but slows things down. 2) CPU as barely used in all time. 3) GS plugin doesn't seem to actually use GPU. And it certainly not because driver doesn't allow it. Pictures above show that pretty damn clearly. 4) Input plugins all kinds of broken (and you continue to ignore it despite detailed description I've gave in other thread). 5) Sound is pretty much the only thing that's working fine. And where the hell one can go from here ? It seems it needs an entire code base audit, long and exhausting, not fun at all.

The real "bug" it seems is exactly with your egoes. And it's you having the gull to blame anyone but yourself for mind-boggling behaviour that only your emulator exhibits in the whole damn world without any good reason. And it would be fine if that would be a proof of concept, 6 month in existence by a single guy without external communication or if you said "yeah, that's weird, probably worth make some tests and find the related code". But that seems to be systematic. Maybe you need to write a whitepaper for yourself about exacts of PCSX2 architecture and a testing suite of small apps for benchmarking basic operations, like ones Mesa and Dolphin have; rethink it or at least see weak spots from "afar" and make an exact TODO about looking into each one. You know, working like a team. Because now that's all over the place.

So, let's do everyone a favour. Let's all shut up. I'll shut up and go minding my own things (I want to make that installable ready-for-any-desktop-out-of-the-box livecd with latest PCSX2 and promote it, after all), you shut up and show the world by deeds and not words how you know best what you're doing and how wrong I am. Because these words now are cheap and deeds are not up to Mesa guys' levels so you could finger point at them (or like they say in Russia: "own's dick is a bad dancer's excuse"). They actually did exactly that and fixed their stuff unthinkably effectively.

[ssakash]

calm down dude, @bositman is remarking about your attitude of making requests with useless comments. I know that most of your report has been constructive and well made but you could have removed the remarks unnecessary to bug. ( I hope that you know what I'm talking about). honestly, those kind of remarks will not at all inspire the coders to get working on the issues but will make them not care about your issues. please avoid those stuffs, Thanks,

So, let's do everyone a favour. Let's all shut up. I'll shut up and go minding my own things

an apology would have been better though, well it's fine ;)

getting back on topic about your issues,

1/ I don't get your point, what do you mean by "Any "speedup" with all EE/VU hacks seems to be a straight up lie for frameskipping that is supposedly "impossible" ?

PS: I understand what you mean, actually the EE cycle rate underclocks the EE for making the game less demanding hence providing a speed up to some games also, the VU stealing has more chances for producing unaccurate FPS, it steals EE cycles for evey VU units run and eventually produces a unsmooth (or) skipping gameplay on most parts.

also, the benefits of MTVU hack is dependent on the games, some games are slown down compared to with MTVU hack disable since some games don't like the VIF1 duplication and it also eventually causes issues like hanging on some rare games. It's an hack afterall but, it does work well on majority of the games. what games are you comparing ?

2/ which games ? I have never had issue with Under utilization of CPU. the problem is most probably on the PCSX2 side, so please wait. :)

3/ how did you come to that conclusion ? try a higher internal resolution and compare the loads with a lower one.

4/ That's a problem on Linux. unfortuanately, @gregory38 is pretty much the only active Linux developer at the moment. and he is also quite busy on taking care of GS related bugs for GSdx opengl so, I don't think this would be done fast. also we only have around 4 active contributors at the moment. https://github.com/PCSX2/pcsx2/graphs/contributors?from=2015-06-05&to=2015-07-11&type=c

please understand the current situation, we will definitely look into the issue (eventually) but we also need somethings from your side. cooperation and patience :)

on the other hand, Thanks for taking your time on making the report with these details. :+1:
though I do hope that you could understand things from our perspective and be helpful on the report side and prevent unnecessary remarks.

[bositman]

1) Any "speedup" with all EE/VU hacks seems to be a straight up lie for frameskipping that is supposedly "impossible". MTVU doesn't seem to load CPU any more but slows things down.

You got it, we inserted some sliders on the GUI so people think they are doing something, but they are actually slowdown hacks! Lulz gotcha!

2) CPU as barely used in all time.

Hey so PCSX2 doesn't use your CPU or your GPU. I guess that's a plus for us, since we can emulate the PS2 without using your PC at all :D

3) GS plugin doesn't seem to actually use GPU. And it certainly not because driver doesn't allow it. Pictures above show that pretty damn clearly.

Amazing insight. I guess GSdx is software emulation after all. Seems your pics prove it :P

4) Input plugins all kinds of broken (and you continue to ignore it despite detailed description I've gave in other thread).

Sorry boss we'll get right to it! Please don't fire us will you? ....get real.

you shut up and show the world by deeds and not words how you know best what you're doing and how wrong I am. Because these words now are cheap and deeds are not up to Mesa guys' levels so you could finger point at them (or like they say in Russia: "own's dick is a bad dancer's excuse"). They actually did exactly that and fixed their stuff unthinkably effectively.

Sorry not interested in proving anything to you or any other kid out there. We've proven our worth the past 13 years this project runs. For the 10th time, if you don't like it GTFO. If you think you can do better, it's open source, fix it yourself and we'll say thank you on top. If you can't, STFU. If you think flaming the developers of an free open source program can motivate them to fix your problems, you're an idiot. These people created PCSX2 so you have something to whine about now, think about it.

I can't see any single bug report, I only see some ranting mixed with some test results along with some 'expert' opinions about what's at fault (which you apparently got no idea about, or you'd fix it yourself) and some flame. That's not how bug reports are made.

I loled at us having to apologize to you. Really, learn some manners.

[v-fox]

( I hope that you know what I'm talking about). honestly, those kind of remarks will not at all inspire the coders to get working on the issues but will make them not care about your issues. please avoid those stuffs, Thanks, an apology would have been better though, well it's fine ;)

Yeah, that's true. But the only way to inspire developers are passion and money. Passion may be not enough for doing boring stuff and I can't help it anyway. I do believe that this work actually should be paid by Ministries of Culture or some kind of foundations from countries with largest PS2 markets as means to promote preservation of cultural and artistic heritage. But that's not happening any time soon.

So, sorry for getting furious about your life's work but you do really need to step up your game to say that other projects are holding yours off.

PS: I understand what you mean, actually the EE cycle rate underclocks the EE for making the game less demanding hence providing a speed up to some games also, the VU stealing has more chances for producing unaccurate FPS, it steals EE cycles for evey VU units run and eventually produces a unsmooth (or) skipping gameplay on most parts.

Yeah, it seems that it not so much "speed" anything up as find a way to throw out falsely "rendered" frames just to come to 50/60 fps and achieve nominal game speed. But even then it manages to dip 5-20fps sometimes.

It's an hack afterall but, it does work well on majority of the games. what games are you comparing ?

As I've written in the beginning: SCUS_974.72;1 "Shadow of the Colossus" and SLES_820.42;1 "MGS3: Subsistence" I assumed that since it's "recommended" and promises multiple threads that it will load cores more and do something useful. Usually you want "recommended" unless it garbles graphics up.

3/ how did you come to that conclusion ? try a higher internal resolution and compare the loads with a lower one.

I took "Shadow of the Colossus" and compared all starting scenes with all possible settings while those realtime performance counting graphs are running (so which I wrote commands above so you could recreate the tests). x1-3 resolution changes doesn't seem to bring much difference, it's barely noticeable. And I was unable to see clear relationship between scene detail and load, unlike as with Resident Evil 4 on Dolphin.

That's a problem on Linux. unfortuanately, @gregory38 is pretty much the only active Linux developer at the moment.

It's alright. But at least acknowledging knowing that something wrong would be nice. What I described about input is something really broken and I have no idea if I did something wrong or everyone sees the same thing.

please understand the current situation, we will definitely look into the issue (eventually) but we also need somethings from your side. cooperation and patience :)

That's cool. I understand. Thanks. It's just that one can't always hide by "it's just a hobby, so piss off" pretext. That's the valid excuse that in no way invalidates the original claim either.

though I do hope that you could understand things from our perspective and be helpful on the report side and prevent unnecessary remarks.

You got it ! I did mean what I've wrote about whitepaper, testing and such though. You really took on something immerse and you can't ignore the danger of regressions and oversight by stumbling blind, I think, risking to dive on pure delusion. Like...

Hey so PCSX2 doesn't use your CPU or your GPU. I guess that's a plus for us, since we can emulate the PS2 without using your PC at all :D

You you can call "shitting under itself", wasting some cycles and missing others a "plus", yeah.

Amazing insight. I guess GSdx is software emulation after all. Seems your pics prove it :P

Seems they do. Where's your pics and a testing kit for comparing performance of basic operation between emulator and hardware or just benchmarking changes that show otherwise ?

Sorry boss we'll get right to it! Please don't fire us will you? ....get real.

You just keep it bitrotting, Ignore the issues, it can only do good things.

If you think flaming the developers of an free open source program can motivate them to fix your problems, you're an idiot.

You are idiot if you think that your project's problems are mine and not yours.

That's not how bug reports are made.

Enlighten me. Or should they all come with ready fixes ? Should someone else do everything for you too ? I still can't see an answer from anyone if that's normal for a plugin not showing any config window or doing anything. What exactly should I report about that ? These are rhetorical questions at this point.

Anyway, my questions about EE/VU and MTVU behaviour are answered. I can move on.