Run UAE, choose 1920x1080 and instead of loading P96 screen it freezes whole os4 system (not just UAE, but everything) exactly when it should show the P96 screen.
Nothing on the serial, just a total lockup.
Tested for sake of test after reboot to hold 2 mouse buttons: aga modes (at least boot screens) shows fine. Issue is with P96 now.
Anyway, tested 8 bit screens, by running previous UAE builds and set/save 1920x1080x8bit.
For first, 8bit renders, yes, but ... It have both speed and "swith screen" issues. Sometime i can't swith normaly between window and fullscreen, everything slow VERY much and produce glitches (maybe because of slow speed, dunno).
Try to just set 1920x1080x8 bit, and run it on 1920x1080x8bit screen : it's not slow, its just unusable. Loading till to see just a top bar of workbench, more than 1 minute. Waiting till everything loads up was so much slow, than i just reboot. Moving of mouse is jumpy and just like you use some 286PC with 15mhz cpu :))
Then i trying to run another time. Waiting 2 minutes : workbench at least show up, but then i give up, and hit combo for quit from uae : screen closed, but in the shell it not exits, and bring me only:
graphics_leave:2105 graphics_subshutdown:2041
And bring a window with "PROCESS something" error (like child can't blablal) of that sort.
So i had to reboot, again.
Next, what i tried is to save as 1920x1080x8bit, and then, start instead on 1920x1080x32bit screen.
This time, it runs. Workbench loads a bit faster (but still, pretty slow, about 20-25 seconds to show top window of workbench). And then, WBDOCK loads only after 2 minutes (!!) and background image loads after 3(!!) minutes.
Mouse movement very slow too, icon drawing very slow.
Through i was able to run somehow (waiting for about 5 minutes in summary) a JP19 mag, and , i can see that 8bit mode works and aga mode works, but it INBELIVABLE slow. Fade in/out of simple pictures looks so slow, that is like dunno what.
So... result is for current tests:
1). P96 32bit broken (that we know already).
2). P96 8bit VERY-VERY slow (i mean, unusable slow, just Uber slideshow). Running of P96 mode on 32bit screen make it renders a bit faster, but still, very, very slow. It take _minutes_ to just load up workbench with background and single dock.
3). Yes, 8bit render correctly. But unusable because of speed for now.
So whatever there happens, it go the wrong route for sure. I can understand that p96-32 route may have some issues need to be fixed, but 8bit is _that_ slow that i can't belive is it how it can be. There something very wrong happens. Like, gazilion of the debug output somewhere (through, i didn't see any).
Even moving of the windowses on the os4 start to be clumsy when 8bit screen loading, CPU metter is crawl at 70% only, but, i assume it just can't update itself because of some real weirdness happens.
I think there something wrong happen, like maybe code going to some loops or something, and not how you expect it to be, because for sure you can't be happy with emulator starting in 8bit mode for 3 minutes :) But work in progress are work in progress :)
The only positive moment there,that at least when i was able to wait 5 or how many minutes to load up JP19 diskmag, i can see that both 8bit and AGA screen works, and resized well, etc.
But, one big "but" : unusable slow. Not "a bit slow", but unbelievable slow. 8bit data is far less than 32bit data, so one can assume that at least loading of 8bit data on 8bit screen should be if not the same as loading of 32bit screen on 32bit, but at least the same or faster.
My bet firstly needs to deal with "speed" issue, and then other issues maybe auto-fixes (like issues with switching, etc).
Edited by kas1e on 2022/12/26 15:03:49 Edited by kas1e on 2022/12/26 15:06:43 Edited by kas1e on 2022/12/26 15:08:07
Well, 8bit has converted before it composited, as long your running WB or opening a 32bit screen, for native 8bit screen its really fast. But generally, is bad idea to use that high resolution for composited images.
there are some stuffs that can be done optimize, the invalid line concept, where it only converts if there was a blit or rect, can work, but also need manage display locks, but then don’t know where on the screen things got changed.
updating colors can be slow, as it now, as I’m updated lookup table every time you change a color, we only need to do it once every vbl, and only if 1 or more colors is changed, not per color.
Not sure if your using the 2pixel conversion, 1 pixel conversion, the 1 pixel conversion is 50% of the speed.
Quote:
but unbelievable slow. 8bit data is far less than 32bit data
it's not less, its more its 8bit + 32bit, before converted and after converted, having to convert from 8bit to 32bit of cause slow things down.
Some of your results, can be interesting to profile, did not someone write profiler tool. What routines are called the most.
Also not sure if function is_vsync() function acutely is called every 60 fps, or if supposed to check if its vbl, if called more often then 60 fps, it might explain some of the issues.
Edited by LiveForIt on 2022/12/26 20:15:13
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@LiveForIt I may wrongly explain it, but this is not about optimization or not optimization, it's in general awful slow. Not like "ok but need optimization", it just totally slow like something heavy broken. Not like "it work but need optimisation". It just uber-ales :)
As i say, if i set 1920x1080x8 bit screenmode in prefs:screenmode, and then run on the same 1920x1080x8bit screen, then it take 3(!!) minute (!!) to just show up loaded workbench.
Just compare it with 15 seconds of truecolor 32bit screen loading with previous commits. Kind of not looks like something which miss optimization, but looks like something totally wrong.
Quote:
for native 8bit screen its really fast.
Absolutely not. At least not with the commit #97. It takes 3 minute to load up the whole workbench when i use 1920x1080x8bit screenmode and open it on 1920x1080x8bit screen.
Let me show you how bad speed is it now, so you will see that it nowhere "fast", but very-very-very-very slow.
And as i say, on 32bit screen opening of this 8bit screenmode EVEN FASTER. That another point to "something very wrong".
So, check this out:
You can see, on the video, i run 1920x1080x8bit screen (and the same i have in picasso96, so all the same). And from 8st second it start loading stuff.
15st second - show top bar of workbench (so take 7 seconds, looks ok).
Now, watich till 01:50. It takes about 1 minute 40 seconds, to show up just WbDock panel. Everything start to be sluggish already. Memory eat like madmenn (400 MB !) .
Then, from 01:50 you can see all the hardcore : how mouse moves everywhere, how opens drawers, how mouse cursor sluggish. In end of all , to show up the background, it take 2:30 . Almost 3 minute.
And, when i stop recording video, i then hit "ctrl+alt+q" to quit. And it didn't exit properly. In the shell it says "graphics_leave:2105 / graphics_subshutdonw:2041" and nothing more. Only reaction based window about issues with processes.
It will like some very, very wrong code happens. As you can see on video, everything sluggish everywhere. In os4 itself, in emulator, everywhere. Like it bang the hardware directly via disable/enable/dunno what. Or like it doing the same rewrite of data thousands of times.
More of it, if you see on video carefully for the "memory" docky, you can see, that opening of this screen, eat 400 (!!) MB of RAM !
Surely something broken.
I surprised how it can work for you at all. Maybe you forget to commit something important lately ? OR maybe commit something which not in the local build ?
My bet, that something very bad with memory. This 400MB eating looks pretty bad, and pretty much possible, that code tries to allocate memory in some bad loop, and never ends, or sometime ends, that can explain those "crawls" of everything. But just a guess.
If you need any more information about, let me know. But its all easy to reproduce really. Just use 1920x1080x8bit.
Quote:
updating colors can be slow, as it now, as I’m updated lookup table every time you change a color, we only need to do it once every vbl, and only if 1 or more colors is changed, not per color.
Can be slow ?:)) Check the video. It's not "can be slow". Its absulutly unusable. 3 minute to load up just a workbench. And try to move anything on the workbench (check the end of video). Opening of drawer take how much, 15 seconds ? :) It's not just "slow". Something broken.
Quote:
Some of your results, can be interesting to profile, did not someone write profiler tool. What routines are called the most.
As i say it's not a matter of optimization. Something really broken. Just check the video. Memory eats, everything crawl, nothing work, 3 minute loading.
Just check the whole video plz.
I can understand if we have 15 seconds till full load of WB in 1920x1080x32bit , and, ok, 25 second till full load of WB in 1920x1080x8bit. But not ! We have 3 (!!!) minute ! And 400 MB of memory takes up.
And i didn't point for now about a fact, that when 8bit mode open in 640x480 (even on just 640x480), it's slow very much in simple fading, which point out on issues with redrawing or whatver , can't know . Only can see what happens.
Do i need to explain it in other form, or this one is enough ?:)
Just we need to be sure, you test exactly what i test : commit #97, right ? This one is how on the video. How you test it for yourself when saying "8 bit fast" ? For me 8bit now, is 10 times slower than 32bit.
32bit workbench with previous commits (at least in 73 one) take 15 seconds to load everything.
8bit workbench (does not matter opened on 8bit real screen or 32bit real screen) - take 2 minute 30 seconds. 150 seconds vs 15 seconds.
I do not know how you can't see it on your local test, maybe you didn't test exactly commit 97, or have something changed localy.
If you in interest to have my IMHO, then what we can do is:
Fix the 32bit rendering. And compare, how it. If 32bit will be give the same 15 seconds as before, then issues is not general one, but only 8bit one. So let it be, optimization and whatever, but at least 32bit mode will be usable. If it will the same 2:30 for loading, it mean that code messed and things broken, so we will know if it general issue, or 8 bit one.
Maybe it will be something general with UAE itself when it come to 8 bit modes support. But firstly need to fix 32bit rendering, so we can know what-where wrong
EDIT: i may try to start apply commit per commit since commit #73 when things working, to find out when things start to be broken for 32bit modes, if it will help at all..
There something strange in your video, it says output is 24bit, that’s the window bitmap. and your able to pull down the screen, so you’re not really running on 8bit screen. are you using custom or ask in your config, because something is strange.
I have OS3.1 installed, not 3.2, it can be OS related for all I know. 8bit on 24bit screens are not as slow as on your system.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
There is something strange in your video, it says output is 24bit, that’s the window bitmap. and you're able to pull down the screen, so you’re not really running on 8bit screen. are you using custom or ask in your config, because something is strange.
Find out why it opens for me on 32bit screen: that was because i set up for "prefs:screens" to open on "like wb" screen, so it hardcore switch to 32 bits. Delete settings, and now can run 8 bit on 8bit.
Quote:
I have OS3.1 installed, not 3.2, it can be OS related for all I know.
I have 3.0, 3.1, 3.2 and 3.2.1: It's all the same with 3.1 or with 3.2, no differences.
Quote:
8bit on 24bit screens are not as slow as on your system.
I made some more tests (with of course removed from prefs:screens hardcore set of the 32bit mode), and update build to your latest commit #100.
Results:
1). 32bit screen works again. It takes the same 15 seconds as before to load the workbench. AGA modes work too as before.
So we can make a conclusion from it, that “slow speed” issue is only with 8bit screens and 8bit opened on 32bit screen.
So, then, i test carefully 8bit stuff:
1). Opening of 8bit P96 screen mode on 8 bit OS4 screen in 1920x1080 takes 35 seconds, and everything "pink". Then, after 20 seconds more, the background image start to looks better, but other things like icons, panel, etc. still remain pink.
See how it:
So to full loading of WB with all the stuff, it takes about 50 seconds. At least visually it is like all ok after 35 seconds, but then after a while something draws more to make background looks better, so i assume draw process is pretty slow there anyway.
2). If on p96-8bit screen opening on 8bit os4 screen i go to UAE's prefs:Screenmode, and choose 1920x1080x32 and hit "Test" everything is black.
The same happens if i open 1920x1080x32 p96 screen on 1920x1080x32 os4 screen, and then choose in prefs:screenmode 8bit mode and hit test : same black.
3). Loading of workbench on 8 bit screen mode on 32bit screen in 1920x1080 takes 2 minutes 15 seconds. And everything slow (even mouse movement). And then i can't quit from the UAE, it halts on exit just like i show before , with "Parent process has tried to exit before all children have" from UAE thread, and in console "pgraohics_leave:2120" and "graphics_subshutdown:2056", but it didn't exit and hold like this.
So if to summary everything, then 32bit modes loads the same fine and fast as before. AGA continue to work the same good as before. 8bit modes kind of work, at least initial steps surely done, but, it's pretty slow. When 8bit opened on 8bit screen, it takes 35 seconds, while if we open 32bit on 32bit screen, it takes 15 seconds. Probably, 8bit on 8bit should be the same 15 seconds ?
There is how it looks like when i run 1920x1080x32bit P96 screen on 1920x1080x32bit OS4 screenmode, and then run "JurassicPack #19" disk mag which for title picture use 8bit screen and for mag itself an AGA screen:
See, 8bit screens renders fine on32 bit screenmode, that for sure, and colors ok too. But as you can see fading is very slow, like emulator very busy to draw 640x480 8 bit screen on 32bit screen. And on exit from mag, you can hear sounds interrupts, like, emulator is very busy with everything and can't even play the sound while fade out effect happens. I assume the same issues happens and on first fade in picture, but as there are no sounds plays at this time, we can only see slow redrawing of frames).
Is there a way how we can speed things up, so it will be at least not _that_ slow when we run 8bit on 32bit ?
Maybe we're doing there some unnecessary conversion somewhere ? I mean, even 8bit on 8bit opens in 35 seconds instead of 32bit on 32bit for 15 seconds.
Btw, i tried also Ephidrena's demo called "Adam Malysz" (when you run that one from workbench, it opens 8bit screen). When on 32bit screen it not just slow, it draws frame by frame visibly :) But when i tried to run it from 8bit screenmode and 8bit screen, then while scaling didn't work, it at least plays ok.
The last video does not look that slow, (as this is 8bit to 32bit) the color change slowness issue was explained before, its the vpal32 lookup table being regenerated per color change, as explained before we do that on vertical blanking to reduce how many times its done.
I have not test it a lot myself, yet. I mostly spend time fixing bug and trying get this thing working. we can of course look at way to optimize things.
Its possible bitmap locking is not the best way to move graphics to the GPU. WritePixelArray can be better alternative, but it saves me trouble of line buffers. Its also possible changing the 8bit bitmap from displayable to non-displayable bitmap can help (moving it from VRAM to system RAM), or it might slow down DX blit’s and DX rect. (Pick your poison)
Displaying a 32bit on 8bit, is not supported, of course relatively easy to do a gray scale conversion. But later its going be redundant, when this becomes automatic, no ASL selector. The AGA dither routine is interesting, but don’t know it works, and I expect some changes are needed to make work with chunky modes.
Edited by LiveForIt on 2022/12/27 10:00:06 Edited by LiveForIt on 2022/12/27 10:01:47
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@LiveForIt At least in the current state as of commit #100, we do have all good the same with 32bit modes and AGA modes, and even have 8bit start to works. So if we can optimize 8bit more, then it can be good for sure.
Quote:
The last video does not look that slow, (as this is 8bit to 32bit)
Workbench is 32 bit mode, what is 8bit on 32 there is only title pics for start/end of disk mag (where this slow fade in/fade out happens and sounds start to be interrupted due to overload of drawing operations probably). Other parts are just real 32bit + AGA.
When we run 32 on 32 it's always fast, yeah. Problem is 8 bit on 32bit being just _very_ slow. And even running 8bit on 8bit is slower in 2 times than running 32bit on 32bit.
Quote:
Displaying a 32bit on 8bit, is not supported, of course relatively easy to do a gray scale conversion.
This one is of no worry for us IMHO. Real life use will be most time just 32bit screen for workbench and running things which ask AGA or 8bit in 640x480 / 640x512 modes.
So if we can speed up the 8bit on 8bit to the level of 32bit on 32bit, then it already will speed up 8bit on 32bit as well.
So, if we can speed up the 8bit on 8bit to the level of 32bit on 32bit.
Your measuring time to fully displayed workbench, that’s a poor benchmark.
it’s not possible to get workbench ready in the same time, using the same background image, where large background image must be color reduced, to be displayed, how long it takes to display that image, depends on the JIT, not AmiGFX output. You can change the background image to a color reduced image, to prevent that from happening. As on a real Amiga.
Quote:
then it already will speed up 8bit on 32bit as well.
does not set the colors the same way, it does not display the same way.
Edited by LiveForIt on 2022/12/27 12:03:05 Edited by LiveForIt on 2022/12/27 12:33:37 Edited by LiveForIt on 2022/12/27 12:34:00
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@LiveForIt Back in time when i code dismag for aga amigas, the reducing of colors + dithering from 32bit image to 8bit image take a half of second for 640x480 screen and on 040 cpu.
And even if dont take wb loading with single background being slower in 10 (!) times: pure show 640×480 image take much longer one may expect, and include sound interuption because of heavy workload.
it halts on exit just like I show before, with "Parent process has tried to exit before all children have" from UAE thread, and in console "grapics_leave:2120" and "graphics_subshutdown:2056", but it didn't exit and hold like this.
this one is interesting, but we need more info, I don’t see this problem, what child process is hanging, I believe there simple fix, I believe there is new function dos.library to sync child processes. The question remains did child process get a request to quit, did main exit nicely or did it call exit() or abort(), ignore normal shutdown process.
Edited by LiveForIt on 2022/12/27 14:37:01
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
the workbench dithering routine always been slow, I guess on slow CPU it makes sense to give it low priority, what can be more important than displaying the icons. So, you can start working.
The CPU resources I do not use will be taken by the JIT compiler and 680x0 emulation, AHI is competing with the JIT compiler, I guess someone need to take look at that code, and make sure sound has higher priority, also it can be caused by sound mixing issues.
however it be possible we can lower latency by creating a thread for display rendering. But this wont effect 8bit on 8bit, as there is no conversion.
so problem most likely elsewhere.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
this one is interesting, but we need more info, I have don’t see this problem, what child process is hanging, I believe there simple fix, I believe there is new function dos.library to sync child processes. The question remains did child process get a request to quit, did main exit nicely or did it call exit() or abort(), ignore normal shutdown process.
This one happens when i use 8bit screens on the 32bit screens. It's enough to start loading it, then, when it start to load "background image" for 2 minutes (yeah..) and i hit amiga+m to swith to os4 screen, and then make UAE screen be active while WB is scrolled down, and hit "ctrl+amiga+q" = then i have this issue.
What i else found, which point out on something bad happens , is when we run 8bit on 32bit mode, and workbench show the top bar, and start loading this single image for 2 minutes long, the swithing to aos4 screen, and moving the windowses around, are very choppy and jumpy. Meaning in UAE hapepens something bad. Like "calloc()" used in the dead loop or something of that sort.
EDIT: Try also that: run the 8bit p96 screen on 32bit os4 screen. Wait ~3 minute until everything loads up (funny yes, 3 minute!). Then, swith to OS4 screen by hitting "amiga+m". And now, try to move any windows on os4. See the problem ? Its like UAE doing something very bad when we load 8bit screens.
Quote:
so problem most likely elsewhere.
Sorry, can't follow who you mean there. What i mean : 8 bit on 32bit is 10 times slower than 32 bit on 32 bit. Ok dithering, ok conversion 2 times to whatever bits and back to 8, but not 10 times slower than loading of the 32bit on 32bit!
Also, it adds something bad that whole system start to be slow and choppy. Not only emulator, but the entire OS4.
The sounds being broken happens _ONLY_ with new 8bit code. If we tried other commits where 8bit produce black screen, sound was fine, and all ok. It's the way how we draw 8bit screens on 32bit screen cause heavy sound interrupts.
And not only sounds. Try to amiga+m to the real os4 workbench as i say, and try to move any window.
In other words, just do this plz:
-- set 1920x1080x8bit in UAE's p96, save, quit -- run UAE with "ask" and choose 1920x1080x32. So we will be 8bit on 32bit screen -- wait 3 minute only WB loads up -- hit "amiga+m". -- start to move any window on os4 workbench. then hit back on the UAE, try to move mouse.
At this point, you will see that something bad happens. Not related to the optimization or not, but to the whole concept. Something just block everything and busy looping. You can't work in OS4 at all at this point, everything slowed down, until you exit from the UAE (and then most luckily will have “process busy” error as well).
See, they're not just “slower or fast”, there are some concept issues somewhere. Why OS4 start to be slow like hell when you only run UAE and do nothing, and want to move window on OS4's workbench screen ? The only explain : heavy busy looping or calloc() or malloc()/free() or never ended copy somewhere, dunno. But CPU even didn't reach 100%, but hits on 73% , and you still can't move anything in usual way on OS4 workbench screen, while the UAE is running on another screen.
To make it short: 8bit on 32bit produce unexpected slowdowns everywhere in whole OS4. Just running workbench in 8bit on 32bit screen, waiting 3 minute to load this up, and trying to move windowses back on the OS4's screen cause heavy hiccups and nothing works.
Edited by kas1e on 2022/12/27 13:22:16 Edited by kas1e on 2022/12/27 13:25:50
@LiveForIT Tested commit #101, and yes, fading in the diskmag is surely much, _MUCH_ better and looks ok. See how title/end pics are shown now on 32bit screen when we run 8 bit based app:
Also tested Ephidrena's demo "Adam Maluzt" (it also open 8bit screen). And, while demo works fine now, and take 39% of cpu only, then when we switch to the OS4 workbench screen, all "jerky" like it was with my tests when workbench loads when we use 8bit on 32bit.
See:
Especially take a note that when demo runs and i switch to amigaos4 screen, everything jumpy and choppy in terms of moving mouse cursor, etc on our OS4 screen. It's like dunno .. 8bit process taking out all the priority ? Because when i run AGA demos, it didn't have such issue for sure.
Btw, on the end of this "demo" video, you can see this bug with process hang when i hit "ctrl+alt+q" to exit from.
Also, there are always some “green line” at the bottom of the 8bit screens.
And, in end, i do check also speed of loading of os3.2.1 with commit #101 (i measure whole loading : wb, image and wbdock)
32bit p96 on 32bit os4 screen : 15 seconds (colors ok, rendering fine) 8bit p96 on 8bit os4 screen : 35 seconds (rendering ok, but colors wrong, everything "pink") 8bit p96 on 32bit os4 screen : 138 seconds (and rendering and colors ok, as expected at least).
So.. With fading changes, it looks like even speed of WB loading changes a bit when we run 8bit on 32bit screen. Still of course pretty low, but step by step :)
32bit p96 on 32bit os4 screen: 15 seconds 8bit p96 on 8bit os4 screen: 35 seconds (all pink/purple) 8bit p96 on 32bit os4 screen: 37 seconds (!) MUCH improved !
So, definitely 8bit p96 on 32 bit screen have fixed this previous massive slowdowns. Now it mostly the same by speed as 8bit on 8bit. and only 2 times slower to compare with 32bit p96 on32bit os4 screen, and not in 10 times :)
Through this issue with choppy/jumpy everything after we use 8bit mode on 32bit for a while, still there.
To reproduce: -- start 1920x1080x32 p96 screen on 1920x1080x32 os4 screen -- load up any 8bit demo, or diskmag (good test can be Elude's "Machinist" demo, or Ephidrena's "adam malyzt"). -- wait till demo end, and try to move mouse cursor and doing anything : you will notice massive slowdown everywhere. -- hitting "ctr+alt+q" will leave us with this “non exit” bug.
Another little issue is that in 8bit, we always have a green line at the bottom.
But speed wise it definitely sane now and ok for 8bit on 32bit. Of course if we can speed up things more, then that will be welcome, but then, it already good enough.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
