Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
57 user(s) are online (42 user(s) are browsing Forums)

Members: 0
Guests: 57

more...
Support us!
Recent OS4 Files
OS4Depot.net



(1) 2 3 4 ... 9 »


The MiniGL thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 803
Thread for MiniGL-related news and issues.

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.

* Links

- version 2.20 (2015): http://os4depot.net/index.php?functio ... river/graphics/minigl.lha
- latest test version by Daniel: http://www.goldencode.de/tmp/mgl.zip
- source codes: http://www.hyperion-entertainment.com ... /branches/updates-kc/src/

* Open issues:

- "suspicious code in mgl_CreateContext"
-

* Fixed issues:

- extension string buffer allocation (r537)


Edited by Capehill on 2019/3/17 7:23:28
   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5536
@Daniel
copy of my last message:

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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5536
@Daniel

So far tried with last mgl2.23 build:

games:

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.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 3146
Copied from the old thread

@Daytona675x

Can you update the version and date binaries ?

Actually we have:

minigl.library 2.23 ( 2-May-2018)
mglut.library 2.21 (30-Nov-2015)

Perhaps both release numbers should be updated at 2.23 ?

   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 3146
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

See grab here: https://ibb.co/wdVMJZF

Are this added automatically from MiniGL ?
With past version of the library i did not remember to have seen it

   Report Go to top

Re: The MiniGL thread
Just popping in
Joined:
2016/3/10 14:15
From Poland
Posts: 50
Sword laser in Jedi Knight:

https://ibb.co/hgNFt8G

Jedi Outcast - Intro:

https://ibb.co/z7BRTqp

   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5536
@samo79
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

See grab here: https://ibb.co/wdVMJZF

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 ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: The MiniGL thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 803
@kas1e

Did you grab the serial logs of new "testgl issue"?

   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5536
@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

Crashed process: testgl (0x5C2C4040)
DSI verbose error description: Page not found in hash table (page fault)
Access not allowed by page protection (protection violation)
Access was a load operation
0: 0181D7B8 5A603990 00000002 4275E5E8 4275E5E8 5ECD99C0 42765C78 00ED02C0
8: 00006FEB ABADCAFE 80000010 00005937 00000324 590CF2C8 00000230 00000000
16: 01FFFF00 01FFFF00 43F00000 0000F043 00100000 65D60000 42765C78 00000010
24: 6FFFE300 4275E5E8 02160000 00ED02C0 01823604 021828D4 4275E5E8 ABADCAFE
CR: 55355995 XER: A000007E CTR: 0181D770 LR: 0181D7B8
DSISR: 00000000 DAR: ABADCAFE

FP0 : FFF8000082004000 0000000000000000 0000000000000000 0000000000000000
FP4 : 3FF0000000000000 0000000000000000 0000000000000000 0000000000000000
FP8 : 0000000000000000 0000000000000000 0000000000000000 43300000800001E0
FP12: 4330000080000280 4330000080000280 6948120531A11314 CA405F207AB0C790
FP16: 9C3115273903CDBC 0F1446FB74B3E2C4 8A86924B501CC9B0 BAE0887C20C24498
FP20: 283740041C6A08E2 8A20756F9592D1F4 1260825EF540E830 0900422EF334C827
FP24: 993E64BE746B60D0 8C763E0261FAD873 2844AB831AC9312E 1114DEB6D0B674B1
FP28: 89FB1696DD96BCF3 4014000000000000 0000000000000000 3FF0000000000000
FPSCR: 82004000

Disassembly of crash site:
0181D690: 90010024 stw r0,36(r1)
0181D694: 93A10014 stw r29,20(r1)
0181D698: 93E1001C stw r31,28(r1)
0181D69C: 83E30000 lwz r31,0(r3)
>0181D6A0: 813F0000 lwz r9,0(r31)
0181D6A4: 2F890000 cmpwi cr7,r9,0
0181D6A8: 41DE005C beq- cr7,0x181D704
0181D6AC: 3FA00200 lis r29,512
0181D6B0: 3BBD5ECC addi r29,r29,24268
0181D6B4: 913E0000 stw r9,0(r30)

Kernel command line: serial munge debuglevel 0

Registers pointing to code:
r0 : native kernel module kernel+0x0001d7b8
r26: native kernel module kernel+0x00960000
r28: native kernel module kernel+0x00023604
r29: native kernel module kernel+0x009828d4
ip : native kernel module kernel+0x0001d6a0
lr : native kernel module kernel+0x0001d7b8
ctr: native kernel module kernel+0x0001d770

Stack trace:
(0x5A603990) native kernel module kernel+0x0001d6a0
(0x5A6039B0) native kernel module kernel+0x0001d7b8
(0x5A6039D0) native kernel module kernel+0x00023604
(0x5A603A10) native kernel module RadeonHD.chip+0x000a4524
(0x5A603A30) native kernel module RadeonHD.chip+0x00015c14
(0x5A603A50) module LIBS:Warp3D/HWdrivers/W3D_SI.library at 0x7F2971CC (section 0 @ 0x41A8)
(0x5A603B00) LIBS:Warp3D.library:_Warp3D_W3D_ClearBuffers()+0x174 (section 1 @ 0 x1ECC)
(0x5A603B20) module LIBS:minigl.library at 0x7F2D95A4 (section 0 @ 0x6580)
(0x5A603B40) testgl:RunGLTest()+0x52c (section 7 @ 0x18C8)
(0x5A603CA0) testgl:main()+0x2d8 (section 7 @ 0x26C8)
(0x5A603D20) native kernel module newlib.library.kmod+0x00002520
(0x5A603D70) native kernel module newlib.library.kmod+0x00003234
(0x5A603F20) native kernel module newlib.library.kmod+0x00003558
(0x5A603F50) testgl:_start()+0x170 (section 7 @ 0x16C)
(0x5A603F90) native kernel module dos.library.kmod+0x00026724
(0x5A603FC0) native kernel module kernel+0x0006b268
(0x5A603FD0) native kernel module kernel+0x0006b2b0

Disassembly of crash site:
0181D690: 90010024 stw r0,36(r1)
0181D694: 93A10014 stw r29,20(r1)
0181D698: 93E1001C stw r31,28(r1)
0181D69C: 83E30000 lwz r31,0(r3)
>0181D6A0: 813F0000 lwz r9,0(r31)
0181D6A4: 2F890000 cmpwi cr7,r9,0
0181D6A8: 41DE005C beq- cr7,0x181D704
0181D6AC: 3FA00200 lis r29,512
0181D6B0: 3BBD5ECC addi r29,r29,24268
0181D6B4: 913E0000 stw r9,0(r30)
Stack pointer (0x5A603990) is inside bounds
Redzone is OK (4)

68k register dump
DATA: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
----> 00000001 - "testgl" Hunk 0000 Offset 00000000 (SegList: 0x1982EB25)
ADDR: 6FFA4000 8325A400 00000000 00000000 00000000 00000000 00000000 5A603620
Page information:
Page not found


As you can see ABADCAFE in DAR , which mean we have accessed uninitialized memory.

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..

I will try now to just run 2 instances and keep they working for a while.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: The MiniGL thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 803
@kas1e

There is no SDL in the stack trace. This line:

(0x5A603B40) testgl:RunGLTest()+0x52c (section 7 @ 0x18C8)

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.


   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2196
@kas1e
Quote:

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.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: The MiniGL thread
Not too shy to talk
Joined:
2015/6/11 8:51
From Cologne
Posts: 281
@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.

_________________
[Facebook] [YouTube Channel]
   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 3146
@Daytona675x

Thanks for the fix, will going to test it

Just some more minor problems to report:

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

See grab: https://ibb.co/QdwHvmv

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

This one:
https://tcrf.net/images/thumb/3/34/Qua ... png/320px-Quake3title.png

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

   Report Go to top

Re: The MiniGL thread
Not too shy to talk
Joined:
2015/6/11 8:51
From Cologne
Posts: 281
@samo79
Quote:
Thanks for the fix, will going to test it

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

_________________
[Facebook] [YouTube Channel]
   Report Go to top

Re: The MiniGL thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 803
@Daytona675x

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 :(

   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5536
@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 :))

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: The MiniGL thread
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 3146
@Daytona675x

Quote:
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

   Report Go to top

Re: The MiniGL thread
Not too shy to talk
Joined:
2015/6/11 8:51
From Cologne
Posts: 281
@Capehill
Quote:
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.

@samo79
Quote:
Yeah tested, problem gone

Very well

_________________
[Facebook] [YouTube Channel]
   Report Go to top

Re: The MiniGL thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 803
@Daytona675x

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 :)

   Report Go to top

Re: The MiniGL thread
Just popping in
Joined:
2016/3/10 14:15
From Poland
Posts: 50
http://www.hyperion-entertainment.com/index.php/news

Shogo: Mobile Armor Division available as digital download for AmigaOS 3 and 4

EntwicklerX Rulez !


   Report Go to top


(1) 2 3 4 ... 9 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project