@Jorge

Quote:

Jorge wrote: @Hans Quote: True. The Friedens said that a MESA implementation would come once a new graphics system was in place. This should include GLSL. My point was that GLSL is a better choice than Cg. The main reason for that is, that vmem cannot be allocated statically (e.g. GPU kernel would need that to load code, etc.). MESA includes all that in the latest 6.x version, but is heavily dependent on DRI (which includes drivers for NVidea and ATI to some extend). Problem is, DRI would take over the HW - which in case of the AmigaOS is in strong conflict with P96 which does not allow anyone else to manage memory in vmem and is not flexible enough to add this functionality.

That's exactly why they're going to replace the underlying graphics system. The new graphics system will allow both 2D/3D acceleration to coexist nicely. Picasso96 and the graphics library will work through the new system. IIRC, Rogue said that, currently, Warp3D wastes 20-30% (or something like that) doing needless reinitialization because of the problem you outlined above.

@all

If all this techie talk is confusing or boring you, my sincerest appologies. However, I find discussing these technical issues very interesting. Therefore, I shall continue.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@itix

"Critical point 1" sounds like what I described, except that one of the "CPUs" is the 68K emulator. How does emulated 68K code get SysBase now?

@CodeSmith

Quote:

The data that is pointed at by address 4 contains a lot of information about the system, including CPU-specific data. That means that there needs to be a separate copy of this data for each CPU, because some parts of it will be different for each CPU. So what would happen is that the code I mentioned in the paragraph above, which checks for address 4, would return a different value depending on the CPU that was doing the memory access.

Have you considered sysbase.liblist and other lists in sysbase
that apps do read and sometimes even write ?
Having multiple sysbases means having multiple list heads
for the same lists.. talk about mess.

_________________
Selur erutangis siht

@Hans

Quote:

It doesn't mean that they wanted people to use it. I thought that they were begging people to use the exec functions instead.

They never did. If it was in docs or in headers it was free for all. It is even legal to access ExecBase memory lists directly. An excerption from my ROM Kernel Reference Manual: Exec, 1987, page 22:

As an example, Exec memory region lists should be accessed only when forbidden.

Quote:

Not marking it as private is definitely asking for trouble though. BTW, how many apps would break if we denied them access to sysbase?

I dont know and I dont think anyone ever cared about it.

Quote:

Anyway, one possibility would be a separate sysbase for each core. No need to clone the OS and run a separate copy on each core, just clone a few parts. If necessary, the MMU could be used to provide the correct sysbase per core.

Does not work because ExecBase pointers are passed around.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

itix wrote: @CodeSmith Quote: SysBase would probably have to be different for each CPU. That's not a huge deal because the first page frame has to be virtualized anyway (the null pointer detection code has to special-case address 4). It does not work. Programs cache and pass ExecBase around and wrong programs could use wrong ExecBase. This option was brainstormed six years ago and it got scrapped quickly.

You mean that they copy the ExecBase structure, or cache the pointer? If they're caching the pointer, the MMU could be used to redirect ExecBase accesses based on which core they're on. That would be much safer than passing different pointers.

Hans

Last edited by Hans on 06-May-2007 at 08:12 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Jorge

Exactly, multiproc's effect will be greatest in the scheduler. I suspect OS4 will have two different schedulers, one for single proc (the one we have now) and a new one for multiproc.

@CodeSmith

First you lecture me in argumentation technique in post #147, and then you descend to this:

Quote:

Oooh. NOW I get it. This has been an OS4 vs MOS ####ing contest all along. Sorry, I should have realized this sooner. We're done here.

Makes me regret editing out the comment about the two-yearold in post #103...

@Hans

Quote:

That's exactly why they're going to replace the underlying graphics system. The new graphics system will allow both 2D/3D acceleration to coexist nicely. Picasso96 and the graphics library will work through the new system. IIRC, Rogue said that, currently, Warp3D wastes 20-30% (or something like that) doing needless reinitialization because of the problem you outlined above.

The problem is textures are handled thru "bitmaps" which require a LockBitMap/UnlockBitmap() to make sure p96 does not move the mem. Textures can be reused, a lock is often not necessary. Currently, there is no way to "cache" that lock in p96, thus a lock is necessary for every (!) access to that mem, thus slowing W3D down significantly. (I was playing around with that a bit in my mesa 4.x port for OS4, and can avoid the locks which gives you about 100% better performance. I would have hoped a flag to allow to mark vmem to be "non moveable" could have been implemented, not yet,though).

oops we are walking away from the subject...

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@itix

Quote:

itix wrote: @Hans Quote: It doesn't mean that they wanted people to use it. I thought that they were begging people to use the exec functions instead. They never did. If it was in docs or in headers it was free for all. It is even legal to access ExecBase memory lists directly. An excerption from my ROM Kernel Reference Manual: Exec, 1987, page 22: As an example, Exec memory region lists should be accessed only when forbidden.

Ok, that definitely makes things more difficult.
Quote:

Quote: Anyway, one possibility would be a separate sysbase for each core. No need to clone the OS and run a separate copy on each core, just clone a few parts. If necessary, the MMU could be used to provide the correct sysbase per core. Does not work because ExecBase pointers are passed around.

See my post above. I didn't mean returning different pointers, although reading what I wrote, that's what it sounds like. I meant, redirecting memory accesses to the different sysbases. I have no idea how difficult that would be because I've never had to directly use the MMU for anything. It sounds feasible though.

Hans

Last edited by Hans on 06-May-2007 at 08:13 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@CodeSmith

Quote:

"Critical point 1" sounds like what I described, except that one of the "CPUs" is the 68K emulator. How does emulated 68K code get SysBase now?

It is the same for 68k and PPC programs. It must be the same because for performance reasons programs tend to cache ExecBase. If the process switches core or passes ExecBase to another process (i.e. as an argument) you are in trouble.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@takemehomegrandma

OK, let me spell it out: it became clear to me that during the entire thread, all you were doing was saying "MOS uses sandboxing and OS4 doesn't so OS4 sucks". I have no interest in "my OS is better than yours" arguments these days, so we're done.

@itix

Except that what Hans says is implemented and the MMU table is restored if a thread gets scheduled for the core and access is redirected on per core lists, etc. (?)

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@Hans

Quote:

You mean that they copy the ExecBase structure, or cache the pointer?

They only cache the pointer.

Quote:

If they're caching the pointer, the MMU could be used to redirect ExecBase accesses based on which core they're on. That would be much safer than passing different pointers.

It could work. You get problems with programs doing FindName() on Exec lists but maybe no showstoppers there. I know the OS4 team has been pursuing multicore support since last autumn or so and maybe have some other ideas there...

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Passing ExecBase to another process sounds like an odd thing to do but I believe you. OK, so then the value returned from reading address 4 can be a "magic" invalid address, and when you deref *that*, you get a page mapped in with data that depends on the running CPU. It is two page faults, but once you've read SysBase, the page is mapped in and there won't be any more.

[Edit] Yep, what Hans said.

Last edited by CodeSmith on 06-May-2007 at 08:36 PM.

@Hans

Quote:

@all If all this techie talk is confusing or boring you, my sincerest appologies. However, I find discussing these technical issues very interesting. Therefore, I shall continue. Hans

I must admit I have cat napped reading threads such as this one. But Hey, discussion is what this place is about. You can discuss whatever meets your TOS fancy as long as it is done in a civil manner. With one or two exceptions I think you guys are doing a fine job.

_________________
Moxee
AmigaOne X1000
AmigaOne XE G4
I'd agree with you, but then we'd both be wrong.

@Moxee

And it beats fretting over the latest antics of the companies involved. This is the best thread I've been involved in for quite a while.

@CodeSmith

Not passing as such, but say you do a

ExecBase *eb= GetMyExecBase();

Last edited by Jorge on 06-May-2007 at 08:46 PM.

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@CodeSmith

Quote:

And it beats fretting over the latest antics of the companies involved.

That is one reason I am reading this thread instead of those.

Quote:

This is the best thread I've been involved in for quite a while.

I only wish I could join in on the discussion intelligently.

_________________
Moxee
AmigaOne X1000
AmigaOne XE G4
I'd agree with you, but then we'd both be wrong.

@Jorge

Hans's suggestion fixes the problem for both cases. In your code sample, GetMyExecBase would just read memory address 4 and eb would contain a "magic" memory address like 0xffff0000. Each process would have a different mapping for the page frame starting at this address, and this would get updated whenever the process gets handed off to a different CPU. You can pass eb around, even to other processes, and it would still work.

[edit] I came up with a much simpler way of doing it

Last edited by CodeSmith on 06-May-2007 at 09:08 PM.

@hatschi

Quote:

hatschi wrote: The entry-level "design" is announced for "Summer 2007". We'll see what happens and how Amiga Inc will miraculously get *legal* rights to *all* required sources to that date.

Hah ! If you'll get your hands on it before December 07 then I'd call
that a miracle.

_________________
AmigaOS or MorphOS on x86 would sell orders of magnitude more than the current,
hardware-intensive solutions. And they'd go faster.-- D.Haynie