What's the best/latest EUAE build for OS4?

@white

It might actually get slower on WinUAE

No idea if it will be slower or faster on WinUAE, because of composition there more data being moved around.

Thanks for the new changes. But they did not help; if at all they made the issue trigger faster for me. With the new binary the slowdown happened after a minute or so with just loading and compiling one example in StormC.

Before, it was quite hard to trigger the issue.

BTW: You can download the new binary from OneDrive. The object behind the link is updated.

@LiveForIt

Just tried the binary compiled by FlynnTheAvatar and found a funny glitch
The A500 disk is pink coloured instead of blue

https://files.fm/u/vwgjn57aw

To be sure i retest the original E-UAE 1.0.0 amigfx and indeed the colors are correct

Problem seems reproducible with RGB16/ARGB16

@samo79

If the colors is bit wrong, not its because it only cares about output depth not color format, HD/RX drivers support only ARGB not BGRA

nothing 16bit is tested.

its green here.

@LiveForIt
yes probably,
try it costs nothing,
I was looking for something faster for the "Voodoo 3"
at higher resolutions.
But I am aware that all builds are for "real systems".

It costs nothing to try them, in fact maybe I'm lucky and it increases the speed in resolution.


Indeed thank you.

@FlynnTheAvatar

Well, the conversion routines are more aggressive, it can be maxing out the data bus.

@LiveForIt

Not sure, if it is caused by more aggressive/intense calculations, uae should be slow from the start, and the performance should not drop suddenly after some time.

Also, this would not explain why a thread keeps running after I quit uae using "CRTL + ALT + Q".

@FlynnTheAvatar

because it’s given too low priority, some other process is given or takes too much.

Quote:

My theory is that something in the background is not getting some resource, while EAUE has bitmap look, its trying to recover, this causing unexpected CPU load, and lockups.

@LiveForIt
Quote:

Something in the background of os4, or of the UAE ?

Anyway, that indeed looks like resources/process issues, but we need to find it for sure, because it may happen any time. Also, strange that when it starts to crawl, you can't quit from the UAE properly.

IMHO, this bug needs to be identified and fixed, as it can happen any time.

@kas1e

Quote:

Yes, this problem, can affects a lot of things, as far as I see its huge performance issue. And effects the OS in ways that, is almost as bad as forbid / permit, complete intuition / bitmap locking mechanism needs a complete review, does it work as intended.

Quote:

The OS, maybe related to hard drive? Do we have good task resource monitor? Where did errors found on the rs232 and reported earlier come from. Any issue in OS or drivers, or related to intuition, I can’t fix anyhow. This issues are for core developers need to look at it, and see if there something, that can be done improve the OS, to make less fragile.

Quote:

I can, but you can't, maybe different versions of OS libs drivers, something behaving a little different. Are you testing with X1000, x5000 or sam460?

Regardering EUAE.

I have a new commit, now it uses WritePixelArray instead of bitmap locking. runs smooth here, hope it helps.

@LiveForIt

Thank you, with the latest version I did not encounter the slowdown issue yet. But this versions seems to be a bit slower than the previous one. But it is still okay on 1920x1080x8bit.

And I am using TuneNet, WookieChat, IBrowse and Odyssey in parallel. With the old version the issue triggered even without using any of these programs.

I am testing with X5000 and OS4.1 FE Update 2 (Kickstart 54.30, Workbench 53.18).

Update:
The version on OneDrive is the latest one now.

@FlynnTheAvatar

It does use line buffers, so it’s not shocking, yeh… I also really want remove last bitmap locking, if possible, I run into some problem so had to put it back.

@LiveForIt
Quote:

To note, i do not have those errors on rs232 on which you point out. Maybe they come to you from some else issue, but in all the tests I do to reproduce the slowdowns of everything, i never ever have anything on serial (while, of course, serial output working, just nothing from the UAE about).

Quote:

IMHO, we can't point to the OS when we didn't find the root cause.

IMHO we need to identify the cause and create a proper test case, the reproducible situation, and only then, when it starts to looks like a real issue in the OS, we can ask this to be fixed. Or, with simple test case it can be explained what wrong with the code and this will help to fix it outside the OS (or making workaround).

But, the first thing we need, is to find where issue exactly and create some test case to reproduce the situation. Because until we didn't do that, saying that it OS should be fixed IMHO too much. :)

Maybe it will be some missing unlocking somewhere, or locking where it shouldn't be, etc. Even a single mistake in the code can cause this.

Quote:

Are you sure that you were able to reproduce the same situation ? I.e., when the thing goes to crawl i can't quit from, but when not, i can. I mean situation when you run UAE from the shell, not from the icon. Because UAE screen and co closed, that for granted, it just didn't exit to the shell properly (you may not see it if you run from an icon).

Quote:

I do test it all on X5000. But can try also on X1000 and Sam460 just to compare and seeing if there are anything different in this regard.

Quote:

Tested commit #110, short verdict : issue gone ! :)

The long story results:

Loading of WB when we use 32bit OS3 on 32bit OS4 screen: 15 seconds

Loading of WB when we use 8bit OS3 on 32bit OS4 screen: 37 seconds.

Loading of WB when we use 8bit OS3 on 8bit OS4 screen: 37 seconds and wrong colors (everything just PINK, as before). And when i start opening drivers so to go to prefs:screenmode, UAE just crashes, in the DX_SetPalette(). In the shell, lots of “using LoadRGB32 to set colors”. Ignore DSI cause lockup of OS4.

See this “pink” issue (click open image in new tab for full-size):



Sadly that we do open 8bit on 8bit, we still need to use any conversion, as theoretical it should be the fastest possible mode IMHO ?

So far, speed of at least WB loading are fine. But maybe the whole usage of the WB when it in 8 bit opened on 32bit screen starts to be a little slower (at least i can notice it with opening of drawer, a little, but still).

I also do test usual diskmags and demos which i use for testing lately, so far seems the same by speed as before. Even some heavy demo from elude/mawi "We Come In Peace" have the same speed of loading, and the same FPS visually.

If the speed is decreases with WritePixelArrays(), then on X5000 i can't notice it much, at least not from the first steps. On X5000 and on X1000 WPA() is hardware accelerated (do not remember about sam460 and peg2, but probably too). So it is also ok to use this one IMHO, but I will do more careful tests.

PS. Is it ok that when we tried to run 32bit OS3, on the 8bit OS4 screen, then it blacks screen + errors ? Of course, it's not something we will do at all, just feel it need to be reported anyway.

PS2. What you think, is it worth to create a config options in the UAE and add both WPA and Lock/Unlock code, so user can choose from ? (and that will be good for tests as well, etc.). Not that this is must, and will be definitely make reading of the code harder and more "ifdefed", but if that can be easy, maybe can help in the tests process.

@kas1e

Quote:

Picasso96 8bit on 8bit does not use conversion.

The colors come from CLUTEntry not from ColorSpec so there not 1 to 1 relation.

This thing is hacking lowlevel picasso96 driver API.
Why can’t set color values direct.

Only OCS/AGA (6bit/8bit) on 8bit full screen needs ditter.

Quote:

Not really, if people want look for bugs in OS, they can use an old commit, anyhow can good idea write up a stress test, to make sure everything works as should under heavy load, less then ideal conditions.

Quote:

this should be fixed now.
Who reads manuals with both eyes open anyhow.

@LiveForIt

Your latest changes broke the icon colors in 32bit/32bit mode:
Icon Color issue

@FlynnTheAvatar

That’s interesting, wondered what color hack in picasso96.c did, I expect it be some kind of big- endian / little-endian was not dealt with the correct way. I did not notice any issue myself, as I have set icon colors to blue.

@LiveForIt
Tested commit #115. Speed same as before, 8-bit to 8-bit color issues fixed, and as Flynn says : in 32bit mode something wrong with the colors of the icons. A bit of blue added. But background image is 100% correct and no problems.

It seems that only icons are affected, and mostly those which have red color, probably. I.e., red swapped on blue looks like. But then my background didn't have red color on, so maybe everything with red color affected.

Once this one will be fixed, it can be about a time to start dealing with all this “pub”, “custom”, “ask” options of e-uae just to finish this p96 stuff, what you think ? Or you have some more plans for P96 ?

Speed wise, 32bit on 32bit now is really very good. Loads up in 15 seconds, everything opens/moves fast, etc. So working from 32bit-on-32bit and running when need it AGA and/or 8-bit prods is the best.


EDIT: oh, was too fast. Find out that switching from window to full screen or from full screen to window mode cause heavy errors and glitches, like, the pointer to the active bitmap area looses somewhere and start draws everywhere.

@kas1e

And only show up on newicons, not magic icons

I think this one is not so easy... might need to put the hack back.

@kas1e

Quote:

unrelated problem.

CTRL+ALT+R and everything looks normal. no idea what happens there.
but I think its good idea to not free bitmap’s if not needed.

@LiveForIT
Quote:

This hack was inside the UAE from the beginning ?

Quote:

That reboot, of course it will reinitialize everything and looks normal :) The issue is about the switch itself in the time when one want. It works before of course, but start to acts like this since some last versions.

Quote:

Looks very much like loosing pointer to bitmap indeed.


PS. Tested commit #116, where you added 15/16bit modes, and picasso of os3 have new modes added ! All of which 15 bits (no 16 bit ones), that expected ?