Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
26 crawler(s) on-line.
 164 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 miggymac:  9 mins ago
 Gunnar:  37 mins ago
 pixie:  1 hr 58 mins ago
 DiscreetFX:  2 hrs 37 mins ago
 DWolfman:  2 hrs 46 mins ago
 cncparts:  4 hrs 20 mins ago
 saipaman4366:  5 hrs 6 mins ago
 Beajar:  5 hrs 25 mins ago
 Rob:  5 hrs 27 mins ago
 agami:  6 hrs 31 mins ago

/  Forum Index
   /  Free For All
      /  Amiga name, assets and IP today: how much is worth?
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 )
PosterThread
cdimauro 
Re: Amiga name, assets and IP today: how much is worth?
Posted on 16-May-2015 6:02:46
#361 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Hypex

Quote:

Hypex wrote:
@megol

Quote:
Yes I agree. PowerPC is crap, IBM Z is crap, ARM is crap. The only processor architecture that is worth talking about is MIPS.


I haven't heard about MIPS in a long time.

It's still alive. It was bought from Imagination Technologies, which is trying to push it on the embedded and Android market segments.
Quote:
Quote:
People not understanding processor architecture making claims based on feelings rather than technical disadvantages is common.


So you you think that MIPS would have been a better choice above all these others?

Personally I don't see any advantage. But I'm partisan.
Quote:
Quote:
But x86 still is a CISC, I need just point out one example:


But where does it sit between crap and worth talking?

Can you elaborate?

@Hypex

Quote:

Hypex wrote:
@broadblues

Quote:
ARGB32 means 32bits in total not the 32bit per channel you are talking about. Hence the confusion.


Yes I know that. But I didn't put it like that. I put it as A32R32G32B32 so there should be no confusion. The only confusion there should be is when I put 256-bits for each pixel when I meant 128-bits.

Maybe you wanted double precision-per-component? FP32 wasn't enough for you.
Quote:
Quote:
Because a normalised floating point number (ie silence = 0.0 loudest = 1.0) has 256 time more resolution than a 16bit number


That makes it sound like 24-bit.

It's 24-bit for precision (mantissa). So, roughly, yes: it's at least 24-bit.
Quote:
But I wasn't restricting the integer math to 16-bit. We have 32-bit since years, 64-bit is common these days

Not on the post-Amiga land.
Quote:
and vectors provide 128-bits.

Even more: AVX2 already supports 256-bit "integer" vectors. AVX-512, which is coming in a few months, will support 512-bit (8 FP64 values packed per vector ).

However it has to be seen how do you want to use such wide vectors size (I'm talking about your 128-bit integers). Doing "normal" integer calculations isn't that practical and not even desirable, except for some particular area (encryption, hashing).

For what we were talking about, floating points are much more interesting.
Quote:
Quote:
You need to look a lot harder then


I still come to the same conclusion after reading up on FP format. The whole value of a 16-bit word in my example is turned into a fraction. It has to be comverted to FP and if positive, multiplied by 0.0000305185094, else if negative muliplied by 0.0000305175781, to bring it into the range of -1.0 to 1.0. Hence my concern.

What's your concern? Do you think that you lose precision this way? It depends on what do you want to achieve.

Yes, in principle if you convert any 16-bit value into the -1.0 to 1.0 range, reverting back may not lead to the same 16-bit value. Do you care about? Why?
Quote:
I'n not talking about recording. I'm talking about using pre-existing samples which happen to be 16-bit in this case. 48Khz if you like.

Taking an example. Say we have this Paula emulator that mixes two 8-bit samples and output is 16-bit. Let's say it halves the samples at mix down because it worked off the assumption that is what the Amiga is doing. A poor routine will divide the samples into 2, add them then ramp up like so:

o = (s1/2) = (s2/2) * 255

As you can see the resolution of each sample was dropped. I think halving is bad anyway but this but a better way would be this:

o = (s1 + s2) * 128

Yes, and then? What do you plan to do with such value, which should be normalized anyway? If you want to get an 8-bit value, you have to divide by two the result. Yes, it's better to do it AFTER the addition, because you're taking care of the LSB of both sample.

But, again, I don't understand your use-case and your concerns about using floating points to manipulate multimedia data.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Amiga name, assets and IP today: how much is worth?
Posted on 22-May-2015 17:39:34
#362 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Quote:
That's not a technical reason.


Technically it's not good to drag baggage around on a hardware design.

Quote:
Nevertheless, your statement has nothing to do with the translation of instructions that you talked about previously.


There's no need to support old 16-bit code for example. An old DOS program cannot be run directly on a modern Windows. And instructions that are built from extension on top of extension is a big stack to manage.

Quote:
To give you a quick answer, absolutely no: directly using the internal "RISC machine" will kill for sure the performance and requires quadruple the memory used for the code.


That would explain why PPC has large 32-bit instructions and needs a few in a row to do simple operations like filling a register with a value.

Quote:
But yes, you can decide to kill binary compatibility, and resort to emulation to let the old binaries run on the new platform.


Windows has a similar way of treating old programs. It only goes back so far. And in a later versions they increased protection so certain programs, such as those "hardware hacking" parrallel registers, set off a trap. So it makes it harder to run old code even if the CPU could.

Quote:
I don't think that we have hardware cursors anymore.


The Radeon has an option for a hardware sprite or software sprite. We've come a long way since the XOR days.

Quote:
It means that even the cheapest and very low-end computer with an integrated GPU can do it without problems...


It's still a lot of memory moved compared to changing a few memory locations. And we are talking aobut AmigaOS here which can lack these GPU drivers on some hardware.

Quote:
Why do you continue to use such obsolete term, which recalls such very old graphic card?


Would you prefer I say SVGA instead? So what's the modern replacement for VGA? Fact is when I turn on my "Amiga" machine I see "VGA" so if it isn't VGA then the firmware needs updating!

Quote:
Now FP32 is very common. All framebuffer based, of course.


Not exactly what I Was thinking but interesting what they are using for colour data.

Quote:
Do you that quantum computers can also solve a VEEEEERY limited set of problems (at good speeds)?


At their core, CPUs do a few basic things. They tend to read memory, which can contain user input, process and make decisions on it. and move memory around.

Quote:
So, again: do you have a better, CONCRETELY USABLE, paradigm to supplant the current ones?


No, I'm not a hardware engineer and I wasn't claiming to be in my post to Hillbillylitre. I'm not going to make any ideas to satisfy you either. The fact is with technology that one can be top of the pops and then someone else comes and knocks them off the perch and blows them away. It may be unlikely to happen since Intel own the world and hardware is just lables now but still possible.

Quote:
I think that you were referring to x64, right?


Yes. Though that X64 tag is a bit presumptuous. When it was rhymed in "86" we knew what it meant.

Quote:
It didn't make sense when it was introduced because there was absolutely no need for it, especially if you think that Commodore's AGA machine not even had an ARGB32 framebuffer!


I didn't see the sense either in jumping from a 4-bit API to a 32-bit one. And yet people have argued with me that it's useful and how you must treat your RGB guns as fully 32-bit and not take shortcuts. Who do I blame for this useless amount of fun!?

AmigaE had the right idea. It supported 8-bit RGB in its support language API regardless of hardware.

Quote:
So, it's MUCH better to talk about ARGB with FP16, FP32, or FP64.


Imagine that, upgrading my idea to A-FP64/R-FP64/G-FP64/B-FP64. That's only 256-bits per pixel or 32 bytes. Ouch!

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga name, assets and IP today: how much is worth?
Posted on 22-May-2015 20:31:02
#363 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Hypex

Quote:

Hypex wrote:
@cdimauro

Quote:
That's not a technical reason.


Technically it's not good to drag baggage around on a hardware design.

Technically what matters is how much the old baggage weights on a modern micro-architecture, which measures in BILLION of transistors.
Quote:
Quote:
Nevertheless, your statement has nothing to do with the translation of instructions that you talked about previously.


There's no need to support old 16-bit code for example. An old DOS program cannot be run directly on a modern Windows. And instructions that are built from extension on top of extension is a big stack to manage.

See above. That's your opinion which is based on the (wrong) assumption that such 16-bit code have a lot of impact in a more modern micro-architecture. That's absolutely not true since, again, current processors use A LOT of transistors. It means that the so called "x86 tax" is negligible.
Quote:
Quote:
To give you a quick answer, absolutely no: directly using the internal "RISC machine" will kill for sure the performance and requires quadruple the memory used for the code.


That would explain why PPC has large 32-bit instructions and needs a few in a row to do simple operations like filling a register with a value.

No, I was referring to a different thing. The internal RISC used by x86 processors uses very long instructions. I remember something like 112 bits (14 bytes) for the Pentium-4. Every x86 instruction generates from 1 to 4 of those "RISC instructions" (uops in short), and has an average size of 3.4 bytes (4.3 for x64)

It means that if such architecture is externally exposed, the same x86 (or x64) program requires 14/3.4 = at least more than 4 times the space needed.

You can image what HUGE impact it will have of the memory hierarchy (from RAM to the L1 cache). That will kill the performance of the system, and this is the primary (but not only) reason why the internal RISC architecture isn't exposed.
Quote:
Quote:
But yes, you can decide to kill binary compatibility, and resort to emulation to let the old binaries run on the new platform.


Windows has a similar way of treating old programs. It only goes back so far.

No, it's much better. Since the APIs are opaque, the old ones can be easily "tunneled" to the new ones (and viceversa). Take a look at how Windows 9x and NT handle respectively the Win16 APIs.
Quote:
And in a later versions they increased protection so certain programs, such as those "hardware hacking" parrallel registers, set off a trap. So it makes it harder to run old code even if the CPU could.

Sorry, I don't understand this.
Quote:
Quote:
I don't think that we have hardware cursors anymore.


The Radeon has an option for a hardware sprite or software sprite. We've come a long way since the XOR days.

We also have bigger and colorful mouse pointers from long time.

Anyway, a single hardware sprite doesn't make difference regarding the general discussion.
Quote:
Quote:
It means that even the cheapest and very low-end computer with an integrated GPU can do it without problems...


It's still a lot of memory moved compared to changing a few memory locations.

Sure, but it's still perfectly handled by the crappest PC hardware in the world.
Quote:
And we are talking aobut AmigaOS here which can lack these GPU drivers on some hardware.

That's the real point: it's useful only if you have multiple screens which are partially displayed. Just to be clear, it isn't a common scenario, and doesn't deserve to be "hardware accelerated".

Blitting the screen portions already solve this problem, with a little effort.
Quote:
Quote:
Why do you continue to use such obsolete term, which recalls such very old graphic card?


Would you prefer I say SVGA instead? So what's the modern replacement for VGA?

Video card or, more general, video subsystem.
Quote:
Fact is when I turn on my "Amiga" machine I see "VGA" so if it isn't VGA then the firmware needs updating!

That's only the firmware. Modern video cards still have a VGA-compatible firmware for legacy reasons, but it doesn't mean that the card is a VGA. It's VGA COMPATIBLE, but it's A LOOOOOOT different and offers A LOOOOOT more.
Quote:
Quote:
Do you that quantum computers can also solve a VEEEEERY limited set of problems (at good speeds)?


At their core, CPUs do a few basic things. They tend to read memory, which can contain user input, process and make decisions on it. and move memory around.

Yes, and quantum computers works very differently and solve only 6 problems (currently) in an much more efficient way. They are not affordable/usable to cover all other, common, needs.
Quote:
Quote:
So, again: do you have a better, CONCRETELY USABLE, paradigm to supplant the current ones?


No, I'm not a hardware engineer and I wasn't claiming to be in my post to Hillbillylitre. I'm not going to make any ideas to satisfy you either. The fact is with technology that one can be top of the pops and then someone else comes and knocks them off the perch and blows them away. It may be unlikely to happen since Intel own the world and hardware is just lables now but still possible.

In theory, yes. And dreaming about it is possible and is done.

But currently the reality is much different. That's why I prefer to talk more pragmatical things.
Quote:
Quote:
I think that you were referring to x64, right?


Yes. Though that X64 tag is a bit presumptuous. When it was rhymed in "86" we knew what it meant.

Sorry, I haven't got it.
Quote:
Quote:
It didn't make sense when it was introduced because there was absolutely no need for it, especially if you think that Commodore's AGA machine not even had an ARGB32 framebuffer!


I didn't see the sense either in jumping from a 4-bit API to a 32-bit one. And yet people have argued with me that it's useful and how you must treat your RGB guns as fully 32-bit and not take shortcuts. Who do I blame for this useless amount of fun!?

Some Commodore engineer? It wasn't the only mistake that they made. Managed made much worse, of course.
Quote:
AmigaE had the right idea. It supported 8-bit RGB in its support language API regardless of hardware.

I don't know AmigaE. I never coded with such language.
Quote:
Quote:
So, it's MUCH better to talk about ARGB with FP16, FP32, or FP64.


Imagine that, upgrading my idea to A-FP64/R-FP64/G-FP64/B-FP64. That's only 256-bits per pixel or 32 bytes. Ouch!

Honestly I think that FP16 for the assets is/will be fine. Internally calculations can be done using up to FP64 (per component) if/when the precision is important.

For the geometry it's already important, since some graphic subsystems use FP64 for coordinate (WPF for sure).

P.S. Sorry, no time to fix errors.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Amiga name, assets and IP today: how much is worth?
Posted on 23-May-2015 16:48:28
#364 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Quote:
It was bought from Imagination Technologies


It has moved around.

Quote:
Can you elaborate?


megol said PowerPC, IBMM Z and ARM is crap. He then brought up x86 but didn't give it a rating.

Quote:
Maybe you wanted double precision-per-component? FP32 wasn't enough for you.


Good point! Although I recall the 68K had 80-bit wide FP math operations so perhaps I'm aiming too small1

Quote:
Not on the post-Amiga land.


Then that is a step backwards. the 32-bit 68K had instructions for doubling up registers and doing 64-bit operations. PPC can duplicate 64-bit with two 32-bit registers or should be able too. PPC also has FPU to store 64-bit in but at that point you may as well use FPU math.

Quote:
Even more: AVX2 already supports 256-bit "integer" vectors.


And it was only recently I read Wikipedia said PPC had better vector unit than Intel. Oh well. It was good while is lasted.

Quote:
However it has to be seen how do you want to use such wide vectors size


Mainly for the size it provides which provides a lot of room. Maybe extreme. Also, when doing things like mixing samples, it would be efficient to use a SIMD operation to add multiple numbers together if possible.

Quote:
What's your concern? Do you think that you lose precision this way?


Somewhat, just the coversion process. Digital data shouldn't end up corrupted, if only slight.

Quote:
Do you care about? Why?


Digital entrophy. What goes in and remains untouched should come out exactly the same.

Of course, there could be some shortcut to converting integer to FP, where the data ends up exact.

Quote:
Yes, and then? What do you plan to do with such value, which should be normalized anyway?


Well it was just an example of mixing an audio buffer. A real word example would be using Audio Evolution to master a mixdown of some multi tracks, which uses AHI, so AHI would need good mixing routines.

But you present a problem with normalzing, as with a live stream you have no constant to provide maximum amplitude with, and trying to do so per buffer could cause jumps and drops in volume.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga name, assets and IP today: how much is worth?
Posted on 23-May-2015 19:29:10
#365 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Hypex

Quote:

Hypex wrote:
@cdimauro

Quote:
It was bought from Imagination Technologies


It has moved around.

Yes, but it was bought from I.T. some years ago, and not it's her property.
Quote:
Quote:
Can you elaborate?


megol said PowerPC, IBMM Z and ARM is crap. He then brought up x86 but didn't give it a rating.

I think that he cited such architecture on purpose to contrast your statement about the x86 one. They all have some legacy stuff, and some use microcode also.

But megal could be more clear about it. I only reported my impression.
Quote:
Quote:
Maybe you wanted double precision-per-component? FP32 wasn't enough for you.


Good point! Although I recall the 68K had 80-bit wide FP math operations so perhaps I'm aiming too small1

Then you have to wait for the next big thing: 128-bit FP.

It'll be integrated in some years. No joking, that my serious opinion about that. Scientific community is already pushing for it (and there are some custom architectures which already provide it from long time), and at some point in the future it'll appears on more consumer hardware.
Quote:
Quote:
Not on the post-Amiga land.


Then that is a step backwards. the 32-bit 68K had instructions for doubling up registers and doing 64-bit operations. PPC can duplicate 64-bit with two 32-bit registers or should be able too. PPC also has FPU to store 64-bit in but at that point you may as well use FPU math.

There are big problems with introducing 64 bits. See the MorphOS x86 thread, were we talked a lot about it.
Quote:
Quote:
Even more: AVX2 already supports 256-bit "integer" vectors.


And it was only recently I read Wikipedia said PPC had better vector unit than Intel. Oh well. It was good while is lasted.

That was the far past, when Altivec was compared to SSE. Take a look at the near past & present, with AVX:
AVX: A leap forward for DSP performance
Latest Intel processors advance embedded DSP and SBC system design
Quote:
Quote:
However it has to be seen how do you want to use such wide vectors size


Mainly for the size it provides which provides a lot of room. Maybe extreme. Also, when doing things like mixing samples, it would be efficient to use a SIMD operation to add multiple numbers together if possible.

But that's different from what you were talking about. This is normal thing for a SIMD unit: process many data together, at the same time.

However, you previously talked about using wide (128-bit) integers. For me it means doing 128-bit math, so 128-bit integer additions, subtractions, etc. That's an uncommon scenarios, and it doesn't make sense to waste the silicon to support such things. Instead, it's better to present ad hoc solutions for the uncommon (but useful) scenarios which requires 128-bit math; I mean cryptography and hashing, for example.
Quote:
Quote:
What's your concern? Do you think that you lose precision this way?


Somewhat, just the coversion process. Digital data shouldn't end up corrupted, if only slight.

Consider that usually they already come from an analog-to-digital conversion, so you already lost part of the original signal.
Quote:
Quote:
Do you care about? Why?


Digital entrophy. What goes in and remains untouched should come out exactly the same.

Another thing which I want to point-out is that what's really important is that the changes to signal are negligible for the humans that will use the results of such lossy operations. So, some loss can be perfectly acceptable if humans are not affected by it.
Quote:
Of course, there could be some shortcut to converting integer to FP, where the data ends up exact.
You need a mantissa which is large enough to hold those integers. 16-bit math -> 32-bit FP is perfectly fine for this.
Quote:
[quote]Yes, and then? What do you plan to do with such value, which should be normalized anyway?


Well it was just an example of mixing an audio buffer. A real word example would be using Audio Evolution to master a mixdown of some multi tracks, which uses AHI, so AHI would need good mixing routines.

But you present a problem with normalzing, as with a live stream you have no constant to provide maximum amplitude with, and trying to do so per buffer could cause jumps and drops in volume.

Even using FP-32?

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle