Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...
   All Posts (Georg)


(1) 2 3 4 ... 35 »


Re: Apollo core and AROS 68k

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Quote:

wawa wrote:

what most urgently remains to be done in graphical department is the problem when using picasso/uae wrapper new opened screen doesnt fit into the video card memory we have a distroted picture (no crash). obviously the screen is being displayed so far it is possible but the rest is rubbish. perhaps offloading the content of background screens from vram to main memory needs to be fixed.


I was about to look into this (before losing motivation again) and IIRC there's just a simple issue that screen bitmaps are locked (bm->locked variable) when visible (to prevent them from being swapped) but later never ever get unlocked even if some other screen bitmap has become the visible ones. So all screen bitmaps stay in VRAM forever. IIRC:

speed:

if there's some gfx functions which the driver does not handle itself, often the fallback functions will be slow or very slow. Even more so with RAM/VRAM swappable bitmaps because of the required bitmap locking. The fallback are not optimized and they never really can be super fast because the AROS gfx system is designed in such a way that it does not rely on having direct access to the gfx driver bitmap (or other bitmaps') pixel data. It could try to obtain direct access in fallback functions, but at the moment it mostly doesn't and so just uses indirect access to pixel data like through putpixel/getpixel or putimage/getimage.

One things which at the moment the uaegfx driver does not handle itself is blits where source bitmap pixfmt is different from dest pixfmt and at least one of the bitmap is in RAM instead of VRAM. For COPY drawmode/minterm at least it should be possible to handle/implement it using HIDD_BM_ConvertPixels (if both bitmaps are uaegfx bitmaps) or HIDD_BM_PutImage/GetImage (if one of the bitmaps is a foreign one). Speaking about drawmodes at least INVERT and CLEAR (bitmap allocated with BMF_CLEAR may trigger this) should be handled, too.

pixel fmt conversion routines: IIRC AROS 68k only has some of the improved ones (the stuff which used to be SYS:tests/patchrgbconv) built in (space constraints in ROM).

graphics.library/Text(): the code which puts the single font chars into the temp bitplane is very unoptimized. This template bitplane is what then gets rendered on screen using BltTemplate(). If someone wants to improve this, he can try to compile/optimize this (rom/graphics/text.c) on AmigaOS (maybe even AOS4 or MorphOS) with a little program which patches this into the system with SetFunction(). Doesn't rely on AROS internals, so no problem (disable antialiasing related stuff on AOS3). Then compare how much slower this is then original AOS function. Then optimize until it doesn't suck anymore ... then contribute back to AROS.

planar bitmaps: internally most AROS bitmaps are bitmap objects (boopsi like), but not all are. Handmade ones (like with InitBitMap()) are not and IIRC even planar bitmaps allocated with AllocBitMap() are not bitmap objects. So during gfx functions this are wrapped into bitmap objects on the fly, because the gfx system only works with this bitmap objects, but not "struct BitMap *" as known from graphics.library. One thing which I have noticed that is stupid/slow in this wrapping is that the planarbm class in SetbitMap() method always calls RegisterPixFmt to register pixfmt of wrapped planar bitmap. So during each and every gfx function with involved planar bitmap a pixfmt is re-registered. Should be changed to do so only if a matching pixfmt wasn't registered already earlier.

icons: loading of stuff like this (also fonts) is slow(er) in AROS, because AROS can be 32 bit, 64 bit, big endian, little endian and there is same code used for all possible variations. In AOS (or AOS4 or MOS) they have endianess fixed to "big endian" and the system is fixed to 32 bit. So they can basically read in this stuff as one chunk like it was one struct in memory. AROS m68k-amiga could have optimized loading, too (#if AROS_BIG_ENDIAN etc. do it like they do in AOS68k land), but doesn't at the moment.




Posted on: 2016/7/17 10:10
Transfer the post to other applications Transfer


Re: osX 64 bit hosted AROS slow very slow, why?

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Tried running AROS as "root" user? (googled for "slow xquartz" or something like that. Know nothing about this otherwise)


Posted on: 2015/12/2 23:38
Transfer the post to other applications Transfer


Re: EdiSyn - A friendly Editor with Syntax highlighting

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Here (AROS hosted debug version, a bit old) what I see is that the editor seems to call MUI_Redraw() on MUI application object. When first starting it, when resizing window, when switching tabs.

Would normally crash/segfault in MUI_Redraw() (trying to access muiRenderInfo(obj)). Added a temp check/workaround to mui_redraw.c to ignore such bad calls.

Posted on: 2015/3/24 0:51
Transfer the post to other applications Transfer


Re: Asl gets stuck..

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
The text editor uses ASL in an unusal way. Most apps do:

AllocAslRequest();
AslRequest();
FreeAslRequest(),

every time the requester is supposed to open. The text editor OTOH only calls AllocAslRequest() the first time, and then reuses it every time in future AslRequest() calls.

ASL handling of such cases may be buggy. Also because internally it is pretty messy because it uses two separate requester structures. One is like the public one from the headers. And the second one is an internal one. If some ~syncing between the structures is done wrong or done at wrong time, it may cause problems for ASL usage cases like in the text editor.


Posted on: 2015/2/6 9:37
Transfer the post to other applications Transfer


Re: m68k emulation on AROS/ARM

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Quote:

cdimauro wrote:

In theory (!) you can do the same with AROS if it's possible to compile it forcing the use of big-endian mode for the used structures.

So, the problem is having a compiler that gives this capability. And I know for sure that there's at least one:
http://www.drdobbs.com/architecture-a ... endian-compiler/240003090
I know even because... I worked on (validated) it recently. :)

However:
- ICC is proprietary & commercial;
- AROS is coupled to GCC
so I don't think that it'll be possible to get a big-endian AROS.


Look for VOS/OpenVOS/Stratus VOS on the net. It's some big endian OS on x86. They have gcc compiler which creates code in such way that machine looks like big endian even if it isn't.


Posted on: 2015/2/3 2:34
Transfer the post to other applications Transfer


Re: debugging aros port of scalos on 68k

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Quote:

wawa wrote:

but what about the inputhandler?


Inputhandlers get params in A0/A1 registers. If ported AROS apps/plugins dont work (strange errors, freezes, crashes) on 68k, but work elsewhere, it's likely unfinshed/incorrect port of such functions with registerized params, because only on 68k they really (have to ) end up in registers, while elsewhere they are like normal C params.


Posted on: 2014/12/17 0:03
Transfer the post to other applications Transfer


Re: debugging

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Quote:

twilen wrote:

EDIT: It also possible aros lddemon does something wrong or differently.


like calling library Init() function in user task, instead of lddemon/ramlib task ...


Posted on: 2014/12/7 5:57
Transfer the post to other applications Transfer


Re: VoxelNoid for AROS

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
You have wrong/out of date headers.

Look at "clib/lowlevel_protos.h", "defines/lowlevel.h", "inline/lowlevel.h".

Correct LVO number for ReadJoyPort() is 5, not 10.


Posted on: 2014/10/30 0:24
Transfer the post to other applications Transfer


Re: Shift it GL i386-aros

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Quote:

ALB42 wrote:
hmm what kind of exception is this?

Floating point? as written there?


Here (AROS/hosted x86) I got this in the middle of level 6:

Program received signal SIGFPEArithmetic exception.
[...]
(
gdbbt
#0  0xa9830177 in setup_sort_vertices (setup=0xa918af84, det=0, v0=0xa93034a0, v1=0xa93034d0, v2=0xa9303530) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/drivers/softpipe/sp_setup.c:359
#1  0xa9830fa3 in sp_setup_tri (setup=0xa918af84, v0=0xa93034a0, v1=0xa93034d0, v2=0xa9303530) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/drivers/softpipe/sp_setup.c:822
#2  0xa9825404 in sp_vbuf_draw_arrays (vbr=0xa918af14, start=0, nr=4) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/drivers/softpipe/sp_prim_vbuf.c:474
#3  0xa98932ed in draw_pt_emit_linear (emit=0xa9185e24, vert_info=0xaafeb1c8, prim_info=0xaafeb24c) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt_emit.c:265
#4  0xa9850593 in emit (emit=0xa9185e24, vert_info=0xaafeb1c8, prim_info=0xaafeb24c) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c:168
#5  0xa9850855 in fetch_pipeline_generic (middle=0xa9185d04, fetch_info=0x0, prim_info=0xaafeb24c) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c:286
#6  0xa985094f in fetch_pipeline_linear_run (middle=0xa9185d04, start=0, count=4, prim_flags=0) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c:345
#7  0xa9854e35 in vsplit_segment_simple_linear (vsplit=0xa91831b4, flags=0, istart=0, icount=4) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt_vsplit_tmp.h:237
#8  0xa9855078 in vsplit_run_linear (frontend=0xa91831b4, start=0, count=4) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_split_tmp.h:61
#9  0xa984e5d2 in draw_pt_arrays (draw=0xa980e204, prim=7, start=0, count=4) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt.c:113
#10 0xa984ef6a in draw_vbo (draw=0xa980e204, info=0xaafeb424) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/auxiliary/draw/draw_pt.c:491
#11 0xa9823e5b in softpipe_draw_vbo (pipe=0xa928e184, info=0xaafeb424) at /usr/local/arosv0/AROS/workbench/libs/mesa/src/gallium/drivers/softpipe/sp_draw_arrays.c:143


Division by zero in sp_setup.c:359, because area == 0.

const float area = (setup->emaj.dx setup->ebot.dy -
                
setup->ebot.dx setup->emaj.dy);

      
setup->oneoverarea 1.0f area;


Btw, better use hardware accelerated mesa for AROS/hosted (SYS:Storage/Libs/mesa.library), or doesn't it work?




Posted on: 2014/7/29 2:10
Transfer the post to other applications Transfer


Re: ObtainSemaphore with plain and simple atomics

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
I don't think this is safe.

If the sem is locked by someone else and you try to add task to wait queue, what if that other task unlocks the sem just a little bit before your task is in the wait queue. Your task waits for semaphore to become unlocked, although it already is, and it may wait forever.

And what if multiple tasks try to add themselves (AddTail()) to the wait queue at the same time (task switch in the middle of AddTail).

In other OSes I think they too need fastpath/slowpath appraoch. Fastpath (atomic based) succeeds if a sem is locked which is currently free. If that fails slowpath has to be used (some kind of protection like Forbid needed).



Posted on: 2014/2/26 10:26
Transfer the post to other applications Transfer



 Top
(1) 2 3 4 ... 35 »




Search
Top Posters
1 paolone
paolone
4239
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3883
4 nikolaos
nikolaos
3651
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2532
7 mazze
mazze
2200
8 clusteruk
clusteruk
2055
9 Kalamatee
Kalamatee
1986
10 damocles
damocles
1789
© 2004-2014 AROS Exec