Before reporting a problem, please do "version full minigl.library" and "list LIBS:minigl.library" to indicate the library version. If you have issues with some 3rd party MiniGL library, please report those issues to people who created it.
With latest one i run about 10 times testgl, then Cube run/exit few times, then Q3 sdl1 version, then Q3 sdl2 version, then cube few times, then testgl 5-7 times,then again q3 sdl2 version,then again q3 sdl1 version, then cube,cube,testgl (10 times) and bllbalbalabllba : works !
What is interesting to know, is was then this issue there was for some time ? I mean, why i got that crashes and with version frmo precompiled_bins.7z, while thos eextensions parts was touched after ? Or , memory overwriten was there all the time way before 2.23 and 2.22 ?
Also , maybe those "instability" issue with libtxc_dxtn wasn't libtxc_dxtn in end ? Maybe worth to try to bring it back and test all stuff again with latest sources ?
Through, one time when i play lot with running/exit few games, few times quake3, and then after a while running the Cube : it then crashes on start the same as before :( But then i can't reproduce it anymore, not with your latest build, not with 2.20 one. Maybe as it crashes on running, its about that thing in context creation about which Capehill made a BZ
@Capehill Tried 3 instances of "testgl" at the same time, and iconify one , then another, and running 4st instance lockup os. I.e. not one by one and exit, but one, iconfiy, another instance, etc, and then lockup.
So its _much_ better now, but still i had lockup with just pure "testgl". Maybe its even only "testgl" related.
Next time i can't just crash it with only 3 instances, but it takes 5 running ones and iconified, then running 6st one / exit, and then uniconify one back and close , and then GR. Even catch the stack trace:
For sake of test i tried minigl.library 2.20 with "testgl" and can reproduce the lockup too !
That what you need to try:
1). start shell 2) testgl &
(so to run it in background in the same console)
3) now start to run new instanses by the same "testgl &" one by one, let's say 10 of them.
4). move all windowses in all directions, and then iconify them all
5). start to deiconify them, and close, and run again and iconify, and play a little like this => crash.
And that even with minigl 2.20 from os4depot. Probabaly can be related to iconify itself dunno.
Edited by kas1e on 2019/3/16 19:55:24 Edited by kas1e on 2019/3/16 20:25:16
Lugaru Cube Quake1 Darkplace Q3 (sdl1 and sdl2 versions) Return to castle wolfstain Smocking guns LettersFall3 NeverBall/NeverPutt
some scene stuff:
nce-trylobyte (music disk) anti-dominium (demo)
editors:
blender lodepaint
All seems to works and renders correctly as before, and they all works. I even tried them running one after one : no lockup or crash.
Or we can bump revisions and release is at it, or if you still share motivation we can try to test the same things with enabled back libtxc_dxtn, as maybe issues happens not because of that, but because of what you fix lately.
Are this added automatically from MiniGL ? With past version of the library i did not remember to have seen it
Yeah, something wrong at left side on top of window, but i didn't have that (not with last verison, not with previous ones). Are you sure you falsely didn't use for this test again that library from Huno ?
It just looks like something from wazp3d which Huno inbuild for version you have from him.
Retest it again with proper hard-reboot, etc and be 100% sure you test correct library
@amiga_os Can't see what wrong there , is problem on first screenshot what is keeps on the wall after sword, and on second one are the shadows on the face ?
Did that part looks any different in compare with minigl 2.20 / 2.21 ?
@Capehill Tried to reproduce it hard now , and can't from first try. Then, i keep about 5 instances working on the screen, and go to street for a hour, then when i back , they all crashes, with the same crash which i catch yesterday.
There is:
Quote:
[HAL_DfltTrapHandler] *** Warning: Fatal exception in task 0x5C2C4040 (Backgroun d CLI, etask = 0xEFD0CCC0) at ip 0x0181D6A0 Dump of context at 0xEFA023E0 Trap type: DSI exception Exception Syndrome Register (ESR): 0x00000000 Machine State (raw): 0x0002F030 Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [FPU on] [IAT on] [DAT on] DSISR: 00000000 DAR: ABADCAFE No matching page found Temporary stack trace: #0: in module kernel+0x0001D6A0 (0x0181D6A0) #1: in module kernel+0x0001D7B8 (0x0181D7B8) #2: in module kernel+0x00023604 (0x01823604) #3: in module RadeonHD.chip+0x000A4524 (0x01D918E4) #4: in module RadeonHD.chip+0x00015C14 (0x01D02FD4) #5: 0x7F2971CC #6: 0x7F4DFED0 #7: 0x7F2D95A4 #8: 0x7F9922F4 #9: 0x7F9930F4 #10: in module newlib.library.kmod+0x00002520 (0x01A82780) #11: in module newlib.library.kmod+0x00003234 (0x01A83494) #12: in module newlib.library.kmod+0x00003558 (0x01A837B8) #13: 0x7F990B98 #14: in module dos.library.kmod+0x00026724 (0x0197D824) #15: in module kernel+0x0006B268 (0x0186B268) #16: in module kernel+0x0006B2B0 (0x0186B2B0) #17: 0x00000000
points to glClear() call. Maybe Daniel can tell what is this:
module LIBS:minigl.library at 0x7F2D95A4 (section 0 @ 0x6580)
I hope also Hans would take a look at the crash. I will try to reproduce it again but if it has to be a some kind of stress test, it will be hard and time-consuming.
As you can see ABADCAFE in DAR , which mean we have accessed uninitialized memory.
Correct. The program has somehow ended up using uninitialized memory.
Quote:
Stack trace point out in end of all on Warp3DNova, but that can be and SDL itself which cause that, and MiniGL, and Nova itself..
Actually, that's clearly MiniGL + Warp3D (the old one). Try not to get the old Warp3D and Warp3D Nova mixed up.
@Capehill
Quote:
I hope also Hans would take a look at the crash. I will try to reproduce it again but if it has to be a some kind of stress test, it will be hard and time-consuming.
Based on the stack trace, the driver is calling IExec->AllocItemPool() but the pointer to the item pool is obviously wrong. Possible reasons why that could happen: - Random memory trashing has corrupted the RadeonHD_RM.resource context (or not so random memory trashing, like an app/lib writing beyond the end of an array - The pointer to said context itself has been corrupted - The RadeonHD_RM.resource context was destroyed, but it's still being used
No idea why any of the above would suddenly happen.
@Capehill Thanks for that fresh thread If a moderator could now please clean up that poor Wings thread, please?
@kas1e Quote:
Also , maybe those "instability" issue with libtxc_dxtn wasn't libtxc_dxtn in end?
May well be! That extension string thingy caused all kinds of undefined trouble, and it probably was pure coincidence that replacing the dxt stuff seemed to improve the situation on my side.
Quote:
For sake of test i tried minigl.library 2.20
Yes, that's what I expected and said yesterday: if you go for it you will get the old 2015 MiniGL lib by Hans to crash / freeze in similar ways. Naturally, after all it's even more buggy than our new version
Quote:
All seems to works and renders correctly as before, and they all works. I even tried them running one after one : no lockup or crash.
Quote:
Tried to reproduce it hard now , and can't from first try. Then, i keep about 5 instances working on the screen, and go to street for a hour, then when i back , they all crashes, with the same crash which i catch yesterday.
I'd say, let's release the current version as 2.23 and remove Hans' old 2015 download from os4depot. The new version apparently is at least equally stable and contains many fixes and new features required for some newer applications. Regarding dxt: I put a new version online for you to check out. If that one behaves equally stable as the other, then I see no reason why not to use it. http://www.goldencode.de/tmp/mgldxt.zip
@samo79 Quote:
Can you update the version and date binaries? ... Perhaps both release numbers should be updated at 2.23 ?
Yes, once we decided which of the two lib variants to use, I'll adjust version numbers, readme etc., and commit everything to the SVN. I'll also update the 7z there. Then we should use those final versions for os4depot too.
Quote:
Have quick tested IoQuake3 and Smoking's guns .. both games now they showed a sort of FPS "broken" counter in the top area of the window... Are this added automatically from MiniGL?
Yes, this is an MiniGL feature, toggle by the env-var MiniGL/FrameStats 1/on. That format string got broken at some point in the past, those broken chars (most likely due to some UTF8 editor madness) should be µs ;) Well, and the output formatting itself completely fails. IUtility->SNPrintf is used for formatting, using C printf-style %4.4f and such. AFAIK SNPrintf doesn't support %f, which explains why it shows only funny f's... Apparently this never worked and I have no idea who the hell put that there. I just fixed that too.
@amig_os I have no idea how it should look Nor if it's different with earlier MGL versions.
@kas1e, Capehill, Hans Regarding that crash ending up inside W3D_SI: maybe give it a try on an R200 system and see what happens?
Quote:
No idea why any of the above would suddenly happen.
Because those guys started to actually poke at it
Other than that, from my side, I'd say: step by step. I think we all agree that we can now more than safely get rid of that antique more buggy 2015 MiniGL on os4depot. Fixing even more bugs is sth. for the next version, especially if it's sth. were you have to stress the system quite a bit to provoke it.
Another issue is related to Quake3 Since pratically forever (using MiniGL 2.20 and even using older version of the library) i have a systematic system freeze when i'm turning back into the main area of Quake 3
What is curious is that freeze happen only when i'm stuck in that specific area, and not in other areas of the game option
Initially i though it was because a buggy version of Quake3 i've used, however i noted that all Quake3 port under OS4 seems affected by this, so or it's a bug of the original source of Q3 or it's MiniGL
Now you can. Just now I updated both versions mgl / mgldxt accordingly.
Quote:
TestGL example of SDL1 leave some garbage graphics on screen as soon as you quit the window, atleast this is reproducible with latest MiniGL 2.23
Actually that's sth. I know from all MGL versions or raw Warp3D stuff. Happens from time to time here, seems to depend on hardware and the weather outside
Quote:
Since pratically forever (using MiniGL 2.20 and even using older version of the library) i have a systematic system freeze when i'm turning back into the main area of Quake 3
Phew, no idea. Sounds as if it could be anything, not even related to MGL. I suggest to file a bug and not to expect too much
Actually both issues have been reported a long ago to Hyperion. For example running MiniGL Gears demo and resizing window can trigger garbage. (Sam440/M9 for example).
Q3 menu freeze has happened from the day one on certain graphics cards (for example M9). It was debugged in ~2008 and W3D never returned from W3D_DrawElements call.
For me it's hard to believe Q3 is buggy. I don't like to blame anyone/thing but for me the most logical place is W3D driver.
People like to blame Q3 but they don't seem to understand that there is no Amiga-specific rendering code in Q3. Draw calls are delegated to MiniGL + Warp3D :(
@Daniel Tried http://www.goldencode.de/tmp/mgldxt.zip , and it all the same in terms of rendering and stability as S2TC was. Just the library size smaller on about 500-600kb with dxt.
I do test the same list as i test with last mgl, so far all the same, run them also one after another, etc.
So its good to keep imho and probabaly worth of made a release with what we have now. Anything else can keep for later, or it all will be forever song called "i found another bug, Daniel should fix it" :)
So if you will bump the revision/date and prebuild everything, i can then take ppc ones, put all nicely in archive, and upload there so all can tests if all is fine, and then os4depot and forget about for a while :))
Now you can. Just now I updated both versions mgl / mgldxt accordingly.
Yeah tested, problem gone
Quote:
Phew, no idea. Sounds as if it could be anything, not even related to MGL. I suggest to file a bug and not to expect too much
Yep I've reported years ago and not only once, i've reported the issue to atleast two Quake 3 porters (first to Max Tretene and then to HunoPPC), then to the old MiniGL mantainers and even in Hyperion forum but no luck ... At some point i give up
@Capehill
Indeed, i have exactly one of this system, Sam440 Flex 800 with Radeon 9250
People like to blame Q3 but they don't seem to understand that there is no Amiga-specific rendering code in Q3. Draw calls are delegated to MiniGL + Warp3D :(
Absolutely. I don't blame Q3 neither. But there's more than MGL and W3D to make Q3 run on AOS4. And both libs rely on others. And then there's the fact that some issues are super hard to reproduce depending on hardware (or simply only appear on some hardware, starting with different gfx cards). So I'm not surprised that those issues aren't fixed yet.
@kas1e Very well! Then I'll clean it up, adjust version numbers, do the commits of the latest fixes etc. and then report back. Won't happen today anymore though.
As I have never seen W3D driver code, it's easy for me to suspect them ;) I don't mean this in a bad way. It just my traces ended up in MiniGL and when we tried to debug W3D using a serial cable, things became too slow to test. It was kinda frustrating. Somebody closed the BZ, I reopened it because it's still there :)
If I remember correctly, Q3 menu (flame anim) drawing is time-based. I was thinking about somehow "seeding" the time parameter to get the freeze immediate but then I lost either time or motivation.
By the way, thanks for the new MiniGL release Daniel, Hans, Bzili, kas1e and others: it's nice to have new features and fixes after many years :)
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
If a moderator could now please clean up that poor Wings thread, please?
