Initial port of new Paint app. NEW VERSION #14

@DAX
FSB 133MHz on peg2 too.

As i see, on sam460 FSB will be 200mhz, so we can test it pretty soon to detect the differences.

Can't found what speed of FSB will be on x1000.

In general, as i see on my old-machines-for-test with winxp (celeron 1.1ghz), there is FSB are only 99.7mhz. And, on readeon7000, on that machine, i have for 640x480 : 90FPS in idle, and 89FPS in USE. Almost no differences, and faster than on peg 2 in indle in 1.5 times (peg2 - 56FPS in idle), but in USE differences are in 4 times ! (peg2 ~20FPS).

So.. everything point us, that all the problems - just bad realisaton of opengl. Buy my personal imho, that is bad realisation of Warp3D, and not MiniGL itself.

Maybe there is some other dependences in HW which make so big sense..

@Gazelle
Its MUI or Reaction ? Anyway, can you send me the sources of it ? I will try it as well as Trixie one, and just we will choice what is better in end.

@kas1e

It was in Reaction. Sorry, no code available because I was using a gui builder to just put it together to make a screenshot and didn't save it.

@kas1e
Quote:
mhhh... that points straight to our 3D drivers then. The huge difference in idle and "use" should be connected to the fact that we don't have hardware transform acceleration.
Anyway, more processing power and bandwidth should help with software trasforms too I presume.
However the sooner we get new 3D drivers the better.

Hans said he needed to finish the 2D ones first but these are well on their way, so 3D should be the next step I guess...

@DAX

Still, all current drivers and current opengl will be the same. Hans works only on drivers for new cards, and OpenGL-Gallium will support only these new cards / new drivers.

And, we can't say that new drivers and new 3d will be normally done. That matter how drivers will be done, how gallium port will be done, and how port of Mesa will be down. It's again lottery, and be in hope that for now Hanz will do all the stuff, and hope that he can do better/optimized code that can do Rogue.

Why i a bit pessimistic about that , because for me, Mesa->Galium->Drivers , make no big sense in compare with MiniGl->Warp3D->Drivers in terms of speed. More of it , Warp3D, it's something a bit "more amiga friendly", which just need speedup in some parts, and make it by speed the same as Goa on morphos (which in general, the same Warp3d, just done in optimized-good-way).

I really can't agree (but i can be wrong), that 200mhz of differences give us only 3 FPS , and only because of software clipping and transformation. IF that done in software, and that is only problem,then 200mhz of difference should make big sense (imho). Problem (imho again) just because of P96/Warp3D realisation.

For now, Morphos have no hardware clipping/transformation for public use. They (developers of 3d drivers for moprhos), for now test it and so on, and it's not public. So, that mean, that current morphos , also have software done T/L/C , and still, it faster in 2-3 times => just bad optimized Warp3D.

Hyperion just think that is not important to optimize Warp3d. Because if they think that is it, we already should have fast 3d. But because we not, then it show us their prioroty (sad, bad and strange).

Rogue also not answer me on last mails about "which bounty we should create, to make blablala". What mean that priority of optimized warp3d/opengl is not in top of list.

@kas1e

There'd be a major drop in CPU usage if LodePaint was converted to a regular, no-busy-wait Exec event loop. You can see it when opening a file. Normally, LodePaint eats about 91% of my CPU in idle state. When the ASL requester opens, Exec takes over and CPU usage suddenly drops to 8%. After you close the requester, the program returns to whatever it does when idle, and we are back at 91%.

@kas1e
Gallium allows easy driver creation, which mean it should give us the chance of having latest generation GPU drivers way earlier than before.
Moreover Warp3D has no support for Pixel/Vertex shaders, so it is a dead end IMHO

@trixie

Imho the main problem - warp3d + p96 combo. Warp3d are unoptimized, and p96 also slowdown it maybe too. + minigl works over all of this.

Dunno what we can do on user-coder level with that such big and major differences between aos4 opengl and win32 opengl.

(Btw, recieved your mail, just not home, can't check, will answer tommorow).

@Dax
Quote:
Easy drivers creation not mean by default that these drivers will be optimized and fast. Lottery and hope imho.

Shaders and alt , it's extensions for new programs, and of course it will be good to have, but that say nothing about speed of the same plain/classic opengl functions. We do not know how faster or slower it will be if compared with our current API combos. Of course we all in hope (and i am too) that it will be radically faster, but how it will be in reality we will know more or less soon imho.

Of course Warp3D is dead end, but still, we have it on all current HW, and OpenGL works over it. So imho, speed up of even current combo should have place (because waiting for gallium-mesa can be up to years).

@kas1e

Quote:
Just tried the latest LodePaint from OS4 Depot. The same file with the same editing causes the same crash.

Aniway I repeat the test on Windows XP (with latest LodePaint 20100703) and I can't get superior benchmark

------------------------
1024 x 768 x 32:
26/27 FPS - when load lodepaint and do nothing while FPS counter are stay stable.
24/25 FPS - when choice "Pixel Brush" with default size 8, and maniacally draw on screen in loop while fps counter not start to be stable
------------------------

This on my:

PC Celeron 2.60 Ghz
512 RAM
ATI Radeon 7000 (32MB) + ATI Radeon Driver 6.14.10.0313
Windows XP SP1

Surely our OS4 driver isn't that better but I think that LodePaint need a huge optimisation too

@RacerX
Yes,i just not write about it to author, because i can't reproduce it. But, i can reproduce that lockups in other times, but its a bit random. When i will found something more or less stable for reproduce the lockup,then i will try to understand why it happens, and then will write to author about.

For example, i have lockup when i create working area, do many works on it, then close, and trying create new one- and have lockup. But not all the time.

Soon will try to fix it anyway. Will be good if you also can write exactly what minor-editing you do. As i understand, you do that:

-- open file
-- scroll by mouse wheel to make all area visibly
-- then do some editing (need to know what exctly and by which)
-- then save_as
-- then type path + filename, or just file name, or ?
-- press save, wait, then lockup after mouse pressing.


@Samo
That is really strange. As i say, on my intel celeron 1.1 ghz , 1gb ram and radeon7000/64mb (driver 8.252.0.0, date 03.05.2006) , i have 42 FPS all the time(for 1024x768x32). Maybe too old driver for you ? Will be nice if you can update driver and check it one more time. Just to be sure that is driver problem. Maybe your opengl on winxp not works at all in HW, and all done in software ? Try the latest ATI driver (that include latest opengl too).

@RacerX
Check plz that thread. Need some help from you.

@All
Anyone who noticed any lockups, plz also check it.

@kas1e
I generally open an image do some quick dirty work, save and close (always work without troubles) however since you asked, I tryed loading several images saving opening others and the program did lock up.
Maybe it has to do with memory release of closed pictures?

@DAX

Quote:

It also lockup just without any save/load references. For example you can just do long-long editing, then apply many filter over it, and then for example choice any area by rectangle tool, and press del (for cut), then you will have lockup. Its lockups one time for me just when i apply filter. One time i have lockup when i just do new working area. And it always on the same addresses pointed to kernel. Its something related to memory imho, yes, as crash says later its "Access was a store operation", so it happenes when somethig trying to write to the some memory(imho). Its something with free/create/write to memory fucntions as i think, but dunno how detect it for now.

Btw, after you will have lockup, can you please reboot, and type in shell "dumpdebugbuffer" and put output related to crash here ? (just want to check, did you on Sam have the same lockups on kernel or not).

@kas1e
it gives me a 2Km long streak of scrolling text! Anyway I grabbed the window here it is:


This is for an ISI, I also got a DSI earlier however, contrary to last time these were recoverable (the app crashed but Workbench stayed up).

@DAX
Earler DSI are more important (that cause that error later). But anyway, i found by MemGuard, that when we press NEW and try to create new area - then it have some problems with allocations.

Did you use "NEW" in menu items at all for make error happenes ?

@kas1e
Could be.... in reality I wanted to open a new picture but sometimes I found myself hitting "new" instead by mistake, so I might very well did something like similar this time too.

@DAX

Can you try please do everything possible in lodepaint, but, not press NEW at all (just to detect it is only one bug, and it is that the bug which cause lockups later, or not)

@Dax

Can you plz download MemGuard (there is direct link) and run it on background like this: run >NIL: memguard (and nothing more).

Then, try to run LodePaint, and try to reproduce lockup. Looks like memguard do the works, and "guard the memory", which (well, for me, on my peg2), make lodepaint works without lockups.

@RaxerX
Basically i am in high interest if you can also test it like that way as i pointed for Dax. Because looks like you only one for who lockup are the same reproducable on the same place all the time. IF no lockup for you will be when MemGuard are running at background, then, its already something positive for found the bastard.

@kas1e

Quote:
OK, here's exactly what I do. (using 1024x768 screen mode)

- Start LodePaint
- Drag the window so it's at the top-left corner of the screen
- Drag the sizer gadget (at the bottom right) so the window doesn't cover the Amidock
- Load the file
- Use the scroll bars so the big title on the right of the page is showing
- Select the 'fill' tool
- Adjust the setting (tolerance?) to about 50%
- Right-click on the red parts of the title to turn it white
- Scroll over to the small title and do the same thing
- Sometimes I used the brush tool to touch up the titles, but I didn't last time
- Select Save_As
- Type a new filename "Cover1a" No path
- Click 'Save'
- Nothing seems to happen
- Wait several minutes
- Still nothing seems to happen so I click the 'Cancel' and close buttons
- Nothing seems to happen
- Click on the exposed part of my Workbench screen
- Total lockup

@kas1e

Quote:

OK, I'll try it with memguard running in the background.