Poster | Thread |
TRIPOS
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 10:51:10
| | [ #101 ] |
|
|
|
Super Member |
Joined: 4-Apr-2014 Posts: 1204
From: Unknown | | |
|
| |
Status: Offline |
|
|
OlafS25
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 11:44:45
| | [ #102 ] |
|
|
|
Elite Member |
Joined: 12-May-2010 Posts: 6321
From: Unknown | | |
|
| @TRIPOS
even without commercial interests a team can have very different team members with very different attitudes |
|
Status: Offline |
|
|
Hypex
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 12:00:21
| | [ #103 ] |
|
|
|
Elite Member |
Joined: 6-May-2007 Posts: 11180
From: Greensborough, Australia | | |
|
| @lylehaze
Quote:
The music is playing, why not dance? |
Why aren't you dancing to the music?
I don't dance to music, I write dance music.
Well that's the excuse I'd like to use for not dancing.
But there is some truth to it. I did spend some time writing some tracker modules in my 20's. In my prime. Which because of their nature would be classified dance music or techno. I wanted to release an album on Aminet but some tracks have been missing for years and I have been unable to track them down (not intentional) from my backups. One missing track being the album title track thus why it is important. And I had a now annoying habit of saving as songs so I need to track down samples as well. It's at the point where I will be reconstructing a broken audio tape, that I had been doing for years, which is in a spaghetti mess that has the missing songs and redoing them by hand. Like the first time they were entered in by hand. |
|
Status: Offline |
|
|
NutsAboutAmiga
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 16:00:38
| | [ #104 ] |
|
|
|
Elite Member |
Joined: 9-Jun-2004 Posts: 12795
From: Norway | | |
|
| @BSzili
Quote:
This is nonsense. Gallium3D is a very low level API meant to streamline 3D driver development, why would games use it directly |
Well my point being is that you have RadeonHD_RM.resource, so you can build what ever 3D api like over that.
I stand corrected about Gallium3D, not being used for 3D games, might have been thinking about different API when I wrote that Vulkan.
https://en.wikipedia.org/wiki/Vulkan_(API)
How ever Gallium3D enabled DirectX support under Wine for Linux users. and Gallium3D enables video acceleration on Linux, so its not useless.
https://en.wikipedia.org/wiki/VDPAU
This what I image, might happen.
RadeonHD_RM.resource -> Warp3D Nova -> OpenGL ES RadeonHD_RM.resource -> Warp3D -> MiniGL RadeonHD_RM.resource -> Warp3D Nova -> MiniGL RadeonHD_RM.resource -> Gallium3D -> DirectX RadeonHD_RM.resource -> Gallium3D -> Vulkan
But who knows, whats going to happen.
Last edited by NutsAboutAmiga on 11-May-2017 at 04:09 PM. Last edited by NutsAboutAmiga on 11-May-2017 at 04:08 PM.
_________________ http://lifeofliveforit.blogspot.no/ Facebook::LiveForIt Software for AmigaOS |
|
Status: Online! |
|
|
Hypex
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 16:22:43
| | [ #105 ] |
|
|
|
Elite Member |
Joined: 6-May-2007 Posts: 11180
From: Greensborough, Australia | | |
|
| @kas1e
Quote:
Sadnboxing will not help as well, as it will have bugs, which no one can/will fix, and all that mess will drive away even that little interest which we have now. Taking aside "just" switch can take 10 or 20 years if we take in account how fast Hyperion works today :) |
Regarding running a host OS on one endian and sandboxing apps that runs on the opposite endian, I would have to disagree that it wouldn't help. Because this has already proven to work. AROS has the software layer executing 68K Amiga apps on an x86 host. Mac did it when going to x86. And perhaps the best example of all is Amithlon where it sandboxed 68K apps in the emulator that ran fast in an x86 JIT compile. And included hooks into the host so native code could be called from emulated code. To the point that people thought it was a native version of AmigaOS and should have replaced OS4.0.
Sure OS4 is a different OS. But it has been done before. So there's every chance OS4 can do it again. |
|
Status: Offline |
|
|
BSzili
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 17:52:01
| | [ #106 ] |
|
|
|
Regular Member |
Joined: 16-Nov-2013 Posts: 447
From: Unknown | | |
|
| @NutsAboutAmiga
Sure, it makes sense to use what's already there. A lot could be done with what A-Eon provided. Still, as you said there could be potential uses for Gallium3D, since it's a standardized API. There are already existing drivers built using it, plus a few high level graphics APIs are implemented on top of it (Mesa/OpenGL being the most important one). Porting these would take less resources than doing everything from scratch, which is why Hyperion chose this route, I presume. Too bad it never materialized. _________________ This is just like television, only you can see much further. |
|
Status: Offline |
|
|
lylehaze
| |
Re: O.S.4.2.R.I.P. Posted on 11-May-2017 23:56:37
| | [ #107 ] |
|
|
|
Super Member |
Joined: 1-Sep-2004 Posts: 1142
From: North Florida - Big Bend area. | | |
|
| The history of Amiga has been quite long and challenging.
That there are so many still involved is testament to the "Amiga Experience". The Amiga could have disappeared long ago, but for those who care so much about it.
And that devoted community has been both a savior and a curse to the Amiga. Those that are still here are quite devoted, and many are confident that their vision of what should happen next is the only correct one.
Some say 68K is the only "true" Amiga. Some believe that x86 is the only path to the future. Some believe that OpenSource is the only possible path to take, and others are working towards a commercial success. Still others are emulating the classics, or even devising FPGAs that can emulate the classic hardware!
There is little to be gained in trying to prove others wrong.
But that never stopped anyone from trying. _________________ question=(2b||!(2b)) |
|
Status: Offline |
|
|
Hans
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 1:13:40
| | [ #108 ] |
|
|
|
Elite Member |
Joined: 27-Dec-2003 Posts: 5066
From: New Zealand | | |
|
| @BSzili
Quote:
BSzili wrote: @NutsAboutAmiga
Sure, it makes sense to use what's already there. A lot could be done with what A-Eon provided. Still, as you said there could be potential uses for Gallium3D, since it's a standardized API. There are already existing drivers built using it, plus a few high level graphics APIs are implemented on top of it (Mesa/OpenGL being the most important one). Porting these would take less resources than doing everything from scratch, which is why Hyperion chose this route, I presume. Too bad it never materialized. |
Gallium3D's advantage is that it's got the GPU manufacturers themselves working on the drivers. That's work we woudn't have to do.
However, there are a few big problems: - The shader compiler uses LLVM, which in turn uses C++11 (or newer) features. So, we'd need an updated C++ stdlib with C++11 functionality - The code isn't as platform agnostic as it should be (IIRC, Gallium3D on AROS uses a Linux kernel compatibility layer) - The API isn't 100% stable. This is a general issue with open-source software, where it's more tolerated to break backward compatibility since all other software "can be recompiled" - The drivers are generally little-endian only, especially since Southern Islands and newer GPUs are little-endian (previous Radeon HD cards were bi-endian)
That last one is a really big deal, and is why AmigaOS has 3D acceleration for Southern Islands cards while PPC Linux is still struggling.** I've had to address this problem from the get-go, whereas their developers focus on little-endian. This actually affected Warp3D Nova's API design, because you can't do endianness conversion on arbitrary data.
Hans
** Actually, PPC Linux is switching to little-endian mode on hardware that supports it, sidestepping endianness problems altogether. _________________ 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. |
|
Status: Offline |
|
|
Hypex
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 8:54:11
| | [ #109 ] |
|
|
|
Elite Member |
Joined: 6-May-2007 Posts: 11180
From: Greensborough, Australia | | |
|
| @Hans
Quote:
So, we'd need an updated C++ stdlib with C++11 functionality |
Or use a cross compiler. I faced this problem as well on some sources. I ended up cross compiling on Linux X64 and may have had to modify a CMake file flag to compile it.
Quote:
** Actually, PPC Linux is switching to little-endian mode on hardware that supports it, sidestepping endianness problems altogether. |
Yes, working around the problem, rather than fixing it. This comes down to supply and demand really. Intel and ARM (and also AMD) supply little endian CPUs to the biggest markets which demands the code is little endian only.
This brings to mind the PPC Notebook. They are creating it for something different but by the time it comes out the CPU will be running in "PC" mode. The PPC will have really turned into a PPC. Not much point saying it's different when it runs in the less human readable but more popular "Intel" mode.
I've said this before of course and perhaps time to stop asking. What is the point of the '-mlittle-endian" GCC switch if it doesn't do anything to help? Why isn't there a [GCC] attribute to specify a datatype as little endian? That would practically solve all problems over night. Well for code that made use of it.
At the end of the day the world doesn't care. Seems there are no C/++ language and compilers that generate truly WYSIWYG portable code. And all coders must presume the bytes come in backwards which I think is a bit low level since you shouldn't need to think about that in high level. Or they are just blasé about it since their code works for them. And they don't need any effort to write proper portable clean code.
At this point perhaps the OS4 GCC should be modified to include an endian attribute? It's modified to generate OS4 code. Sure it would be non standard but it could help with existing and future code.
The following instructions look useful for reading/writing data from compiler generated code: lwzx/lwbrx; lhzx/lhbrx; stwx/stwbrx; sthx/sthbrx. |
|
Status: Offline |
|
|
tlosm
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 10:02:50
| | [ #110 ] |
|
|
|
Elite Member |
Joined: 28-Jul-2012 Posts: 2746
From: Amiga land | | |
|
| @Hans
Quote:
ands cards while PPC Linux is still struggling |
Exactly strange but true 3D on RadeonSi board is better on OS4 than linux in PPC world .. .thanks to your job.
About PPCel the using of little endian made the linux advantage to have optimized mesa and no more endianess... but at same time disable the altivec optimization on Power8. I dont remeber if this issue is closed on Power9 _________________ I love Amiga and new hope by AmigaNG A 500 + ; CDTV; CD32; PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB; MacBook Pro Retina I7 2.3ghz; #nomorea-eoninmyhome |
|
Status: Offline |
|
|
wawa
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 10:03:13
| | [ #111 ] |
|
|
|
Elite Member |
Joined: 21-Jan-2008 Posts: 6259
From: Unknown | | |
|
| @Hans
Quote:
IIRC, Gallium3D on AROS uses a Linux kernel compatibility layer |
what is that linux compatibity layer? posixc.library? |
|
Status: Offline |
|
|
Jose
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 13:39:50
| | [ #112 ] |
|
|
|
Cult Member |
Joined: 10-Mar-2003 Posts: 992
From: Unknown | | |
|
| "Actually, PPC Linux is switching to little-endian mode on hardware that supports it, sidestepping endianness problems altogether."
Won't that lose AltiVec ? I remember reading somewhere that AltiVec only worked on big endian mode.
_________________
José |
|
Status: Offline |
|
|
wawa
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 14:49:45
| | [ #113 ] |
|
|
|
Elite Member |
Joined: 21-Jan-2008 Posts: 6259
From: Unknown | | |
|
| @Jose
i think when talking of little endian he is referring to rtg modes, not to the system ensiannes as such. already amiga rtg cards provide different endian modes, depending on their hardware. the current graphics cards have all dropped big endian any way i think. |
|
Status: Offline |
|
|
BSzili
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 15:55:58
| | [ #114 ] |
|
|
|
Regular Member |
Joined: 16-Nov-2013 Posts: 447
From: Unknown | | |
|
| |
Status: Offline |
|
|
Rob
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 17:08:08
| | [ #115 ] |
|
|
|
Elite Member |
Joined: 20-Mar-2003 Posts: 6344
From: S.Wales | | |
|
| @wawa
In the last section of his post Hans is talking about Linux itself in the last section and not the video hardware drivers.
|
|
Status: Offline |
|
|
wawa
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 17:09:57
| | [ #116 ] |
|
|
|
Elite Member |
Joined: 21-Jan-2008 Posts: 6259
From: Unknown | | |
|
| @BSzili
i recall a bit the "per opener" debate.
Quote:
A only a few Linux kernel functions were needed: |
the text isnt precise about how that has been solved. one would have to look at repo history, but whatever. i simply tried to understand, where that "linux compatibility layer" claim was coming from. people are accusing aros to be more linux than amiga on cetrain ocassions, which isnt actually corresponding to facts, i fear. |
|
Status: Offline |
|
|
Hans
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 22:30:48
| | [ #117 ] |
|
|
|
Elite Member |
Joined: 27-Dec-2003 Posts: 5066
From: New Zealand | | |
|
| @Hypex
Quote:
Hypex wrote: @Hans
Quote:
So, we'd need an updated C++ stdlib with C++11 functionality |
Or use a cross compiler. I faced this problem as well on some sources. I ended up cross compiling on Linux X64 and may have had to modify a CMake file flag to compile it. |
Cross-compilation won't help because we still need a native C++11 stdlib. That's the bit that's missing.
@wawa
Quote:
wawa wrote: @BSzili
i recall a bit the "per opener" debate.
Quote:
A only a few Linux kernel functions were needed: |
the text isnt precise about how that has been solved. one would have to look at repo history, but whatever. i simply tried to understand, where that "linux compatibility layer" claim was coming from. people are accusing aros to be more linux than amiga on cetrain ocassions, which isnt actually corresponding to facts, i fear. |
Deadwood (who did the Gallium3D port) told me about the Linux kernel emulation/compatibility layer. I have no idea what it's called, but he told me that the Gallium3D nVidia driver was riddled with libdrm calls, which in turn is a Linux kernel module. Making the driver truly platform independent (as it should be) would have been a lot more work. Thus, the use of libdrm + some kind of Linux kernel compatibility layer.
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. |
|
Status: Offline |
|
|
wawa
| |
Re: O.S.4.2.R.I.P. Posted on 12-May-2017 23:10:06
| | [ #118 ] |
|
|
|
Elite Member |
Joined: 21-Jan-2008 Posts: 6259
From: Unknown | | |
|
| @Hans
mhm, ok, thx for explanation ;) |
|
Status: Offline |
|
|
amigang
| |
Re: O.S.4.2.R.I.P. Posted on 28-May-2017 21:15:25
| | [ #119 ] |
|
|
|
Elite Member |
Joined: 12-Jan-2005 Posts: 2018
From: Cheshire, England | | |
|
| on the Workbench Explore review, the screenshot taken says AmigaOS4.2Beta and its 225mb compared to OS4.1 210mb in size.
so has OS4.2 reached Beta!?
would surprise me if it passed alpha, but then they may not use the different terms in amigaOS world! still nice to see.
Last edited by amigang on 28-May-2017 at 09:15 PM.
_________________ AmigaNG, YouTube, LeaveReality Studio |
|
Status: Offline |
|
|