Click Here
home features news forums classifieds faqs links search
6101 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
19 crawler(s) on-line.
 9 guest(s) on-line.
 1 member(s) on-line.


 AP

You are an anonymous user.
Register Now!
 AP:  4 mins ago
 Varthall:  7 mins ago
 Mobileconnect:  7 mins ago
 sTix:  41 mins ago
 Frank:  59 mins ago
 BSzili:  1 hr 13 mins ago
 BigD:  1 hr 20 mins ago
 Vidar:  1 hr 41 mins ago
 jacknife:  2 hrs 2 mins ago
 Rob:  2 hrs 10 mins ago

/  Forum Index
   /  Amiga General Chat
      /  AmigaOneX5000 Review
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 Next Page )
PosterThread
duga 
Re: AmigaOneX5000 Review
Posted on 27-May-2017 11:03:54
#41 ]
Regular Member
Joined: 1-May-2012
Posts: 212
From: Unknown

@amigakit

Yes, Amiga Forever included, but not Enhancer Software? Strange.

_________________
Aros Retrofit

 Status: Offline
Profile     Report this post  
Aslak3 
Re: AmigaOneX5000 Review
Posted on 27-May-2017 11:58:03
#42 ]
Regular Member
Joined: 21-Aug-2012
Posts: 268
From: Southampton, UK

Linked from Slashdot.org now. :)

_________________
Blog

 Status: Offline
Profile     Report this post  
outrun1978 
Re: AmigaOneX5000 Review
Posted on 27-May-2017 11:59:46
#43 ]
Cult Member
Joined: 22-Feb-2015
Posts: 593
From: Unknown

@duga

yes that is a bit strange that AOTL appears from the photo to have packaged the reviewer a copy of the Amiga Forever package instead of the Enhancer Software pack.






_________________
Amigaone X5000/20 4GB Radeon RX 550 Polaris 12 AmigaOS4.1 Final Edition Update 1
Amiga 1200 Workbench 3.1.4
Amiga CD32

 Status: Offline
Profile     Report this post  
Rob 
Re: AmigaOneX5000 Review
Posted on 27-May-2017 14:22:18
#44 ]
Elite Member
Joined: 20-Mar-2003
Posts: 6056
From: S.Wales

@outrun1978

I think he got the New to Amiga bundle at the same time since he's got a copy of 4.1FE Classic in the box too.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOneX5000 Review
Posted on 27-May-2017 16:08:09
#45 ]
Elite Member
Joined: 6-May-2007
Posts: 10256
From: Greensborough, Australia

@All

Did you hear this one?

"The AmigaOne X5000 features a Dual-core Freescale CPU up to 2.5GHz, supports up to 64GB RAM, 6 USB ports, 2 Ethernet jacks, a serial port and priced at $1,840 represents good value for money."


 Status: Offline
Profile     Report this post  
number6 
Re: AmigaOneX5000 Review
Posted on 29-May-2017 19:13:51
#46 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11237
From: In the village

@thread

If you're bored with AW opinions...

over 300 comments from 140 posters atm

Click on "Reader Comments"

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

 Status: Offline
Profile     Report this post  
Hans 
Re: AmigaOneX5000 Review
Posted on 30-May-2017 0:37:38
#47 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4927
From: New Zealand

@number6

Quote:

number6 wrote:
@thread

If you're bored with AW opinions...

over 300 comments from 140 posters atm

Click on "Reader Comments"

#6

Yes, glancing over that's an entertaining read. That said, there are plenty of "AW opinions" over there too. People like cdimauro are writing whole essays.

Just nit-picking on something cdimauro wrote:
Quote:
It's interesting to note that, since you have to map even the video memory in such 2GB address space, buying a video card with a lot of built-in memory doesn't make sense, since only a small portion will be used.
Yes, the infamous memory banking technique can be used even for this type of memory, but... it's up to the developer to use it. Imagine how "trivial" is porting a modern game which uses plenty of video memory (and system memory too)...

Correction, modern GPUs only make about 256 MiB accessible to the CPU so that it doesn't take up too much address space.** Added to that, VRAM is placed in the upper half of the available 32-bit 4GiB range, so you can still use 2 GiB RAM with zero issues.

Next, using the extra VRAM will NOT require memory banking of any sort. The GPU can access it all linearly, and I already designed the RadeonHD_RM.resource's API in such a way that the extra VRAM can be used easily. What's currently missing is the memory allocator and code needed to copy data to/from the additional VRAM. Once that's in place then existing 3D apps will be able to use the entire VRAM space with ZERO developer effort (yes, even 8 GiB if you were nuts enough to buy a card with that much VRAM).

Hans


** Most recent GPUs do have a PCI extension that allows the PCI VRAM BAR to be resized later, but support for that seems to be a bit patchy. Southern Islands GPUs don't have that extension, so it's irrelevant for us right now.

Last edited by Hans on 30-May-2017 at 12:38 AM.
Last edited by Hans on 30-May-2017 at 12:37 AM.

_________________
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
Profile     Report this post  
cdimauro 
Re: AmigaOneX5000 Review
Posted on 30-May-2017 22:29:07
#48 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2257
From: Germany

@Hans

Quote:

Hans wrote:
@number6
[...]
Yes, glancing over that's an entertaining read. That said, there are plenty of "AW opinions" over there too. People like cdimauro are writing whole essays.

Thanks for the compliment.
Quote:
Just nit-picking on something cdimauro wrote:
Quote:
It's interesting to note that, since you have to map even the video memory in such 2GB address space, buying a video card with a lot of built-in memory doesn't make sense, since only a small portion will be used.
Yes, the infamous memory banking technique can be used even for this type of memory, but... it's up to the developer to use it. Imagine how "trivial" is porting a modern game which uses plenty of video memory (and system memory too)...

Correction, modern GPUs only make about 256 MiB accessible to the CPU so that it doesn't take up too much address space.**

Correction, modern GPUs allows much more than 256MB of Aperture Size. Example

And you know that the bigger is this window, the less need to shuffle video segments you have.
Quote:
Added to that, VRAM is placed in the upper half of the available 32-bit 4GiB range, so you can still use 2 GiB RAM with zero issues.

Now you're talking about VRAM, which is different from the above Aperture (which is the only one that a CPU can access).

OK, you can remap it in the upper 2GB, so you save a lot of space from traditional (and only usable) address space, but you also need to map the above Aperture.

To be more clear, assuming that your video card has 2GB and you set a 256MB Aperture size, what happens? Do you remap the Aperture to the high 2GB, hence removing 256MB of addressable VRAM (or you can continue to shuffle video segments, remapping them in the Aperture as needed), or do you remap the Aperture in the traditional (low) address space (hence keeping the whole VRAM in the high 2GB, but "eating" 256 of system RAM)?
Quote:
Next, using the extra VRAM will NOT require memory banking of any sort. The GPU can access it all linearly, and I already designed the RadeonHD_RM.resource's API in such a way that the extra VRAM can be used easily. What's currently missing is the memory allocator and code needed to copy data to/from the additional VRAM. Once that's in place then existing 3D apps will be able to use the entire VRAM space with ZERO developer effort

I never talked about the GPU before (I was always referring to the CPU). It's quite obvious that the GPU can access all of its VRAM, without limitations.
Quote:
(yes, even 8 GiB if you were nuts enough to buy a card with that much VRAM).

Eh. It looks like the story of fox and the grapes.

You should know that video cards are becoming more powerful and/or cheaper, while bringing much more integrated VRAM. And you should know that, at least on the PC land, 4GB of VRAM aren't enough anymore for the most modern games that have plenty of ultra-detailed textures, displayed on 4K (or 5K) displays.

You can say that 8GB of VRAM are useless in the post-Amiga land, because there aren't modern games, and people are happy to run Quake at 640x480...
Quote:
Hans

** Most recent GPUs do have a PCI extension that allows the PCI VRAM BAR to be resized later, but support for that seems to be a bit patchy. Southern Islands GPUs don't have that extension, so it's irrelevant for us right now.

Sure: you're talking of video cards of almost 5 years and half ago. Nothing new, since it's a very old technology, with much less VRAM on board compared to now.

Nowadays video cards have plenty of VRAM, and GPUs are also used to do something other than just displaying graphics. Hence, it was already introduced time ago the possibility to have a common virtual address space between CPU(s) and GPU(s).
Have you ever listened about the so called IOMMU? Or the shared address space which is available by OpenCL? Intel also introduced years ago the possibility to have a common address space between CPUs and GPUs (it's called MYO: Mine, Yours, Ours), with its HPC solution (Xeon Phi).

This is the current trend, and with good reasons, since having a shared address space brings a lot of advantages.

But using such approach in a 31/32-bit o.s. like OS4 (but even MorphOS and AROS/32-bit) is overkill, since you can easily run out of space when manipulating a lot of data which is shared with the GPU, and with the single address space shared by all applications & o.s..

P.S. According to what you've said, I've no problem regretting from the banking technique applied to the VRAM too: it doesn't apply. But that's the only point, whereas I've written plenty of stuff on Ars Technica.

 Status: Offline
Profile     Report this post  
Hyperionmp 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 0:01:07
#49 ]
Hyperion
Joined: 8-Mar-2003
Posts: 502
From: Unknown

@Hans

Interesting read and set of facts. Coming from you, I have no doubt they are accurate as you are actually one of the few people in the world outside AMD who actually develops drivers for these cards.

But as per usual the facts won't bother some individuals.

"Alternative facts" seems to be all the rage these days and not just in the US, sadly.

Last edited by Hyperionmp on 31-May-2017 at 12:01 AM.

_________________

 Status: Offline
Profile     Report this post  
jorit2 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 0:18:15
#50 ]
Regular Member
Joined: 22-Apr-2011
Posts: 243
From: Unknown

@Hyperionmp

Quote:

"Alternative facts" seems to be all the rage these days and not just in the US, sadly.


I don't think you're well placed to make a statement such as this one

Evert

_________________
-- Posting for charity -- Investing 10 in a charity related to education or civil rights for every message I post --

 Status: Offline
Profile     Report this post  
Hyperionmp 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 1:31:58
#51 ]
Hyperion
Joined: 8-Mar-2003
Posts: 502
From: Unknown

Hands up who has an American passport?

Not me!

Last edited by Hyperionmp on 31-May-2017 at 01:45 AM.

_________________

 Status: Offline
Profile     Report this post  
jorit2 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 1:35:42
#52 ]
Regular Member
Joined: 22-Apr-2011
Posts: 243
From: Unknown

@Hyperionmp

Quote:

Hyperionmp wrote:
@jorit2

Well, you have the American passport, not me so that makes you the expert :)

Let's agree to both take our medication :)


I guess you missed the point intentionally

Evert

_________________
-- Posting for charity -- Investing 10 in a charity related to education or civil rights for every message I post --

 Status: Offline
Profile     Report this post  
Hans 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 1:42:25
#53 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4927
From: New Zealand

@cdimauro

Quote:

cdimauro wrote:
Quote:
Correction, modern GPUs only make about 256 MiB accessible to the CPU so that it doesn't take up too much address space.**

Correction, modern GPUs allows much more than 256MB of Aperture Size. Example

I already covered the adjustable aperture size in my footnote. The standard default aperture size is 256 MiB.

Quote:
And you know that the bigger is this window, the less need to shuffle video segments you have.

Not really. As a general rule, you don't want the CPU accessing VRAM directly. Instead, data is copied to/from VRAM using DMA and GART (which is more of an IOMMU these days). The GPU's DMA engines can access all RAM and VRAM irrespective of the PCI aperture.

The one reason you want full VRAM to be visible via the PCI aperture is so that there is one physical address space (i.e., the CPU and GPU use the same addresses for everything). That simplifies managing everything.

Yes, using GART & the GPU's DMA engine is still on the longer-term to-do list for AmigaOS. So for us the transfers are still on the slow side at the moment. However, once you have your gigabytes of textures and vertices in VRAM, the GPU will access them at full speed.

Quote:
Quote:
Added to that, VRAM is placed in the upper half of the available 32-bit 4GiB range, so you can still use 2 GiB RAM with zero issues.

Now you're talking about VRAM, which is different from the above Aperture (which is the only one that a CPU can access).

OK, you can remap it in the upper 2GB, so you save a lot of space from traditional (and only usable) address space, but you also need to map the above Aperture.

To be more clear, assuming that your video card has 2GB and you set a 256MB Aperture size, what happens? Do you remap the Aperture to the high 2GB, hence removing 256MB of addressable VRAM (or you can continue to shuffle video segments, remapping them in the Aperture as needed), or do you remap the Aperture in the traditional (low) address space (hence keeping the whole VRAM in the high 2GB, but "eating" 256 of system RAM)?

Here's how it works. 2GB of RAM is fully available, because the VRAM's 256 MiB PCI aperture is in the upper half of the available 32-bit 4 GiB address space. So, no sacrifice of RAM necessary.

What about all that extra VRAM? In AmigaOS' case, Picasso96 only knows how to use the first 256 MiB. The rest of the graphics card's VRAM will be managed by the RadeonHD_RM.resource. So, 3D drivers will be able to allocate parts of the additional space, and copy data to/from it. The data transfer is managed by the driver, so app developers don't have to worry about how. No remapping or banking will be performed.

Where is this extra VRAM in the CPU's address space? Nowhere; it's in the GPU's address space, and is managed as such. So yes, we'll eventually be able to use 8GiB+ VRAM despite having a 32-bit OS... once I've written the necessary code.

Quote:
Quote:
(yes, even 8 GiB if you were nuts enough to buy a card with that much VRAM).

Eh. It looks like the story of fox and the grapes.

Surely you agree that it is a little crazy plugging a graphics card with 8 GiB of VRAM into your AmigaOS machine when it can currently only use 256 MiB, right? Once the drivers enable using all VRAM it'll be different.

Ironically, my post was to counter your claims about large amounts of VRAM and memory banking. I'm glad you've conceded that this isn't necessary.

I know of at least one AmigaOS user with a >=4 GiB card, BTW.

Quote:
Nowadays video cards have plenty of VRAM, and GPUs are also used to do something other than just displaying graphics. Hence, it was already introduced time ago the possibility to have a common virtual address space between CPU(s) and GPU(s).
Have you ever listened about the so called IOMMU? Or the shared address space which is available by OpenCL? Intel also introduced years ago the possibility to have a common address space between CPUs and GPUs (it's called MYO: Mine, Yours, Ours), with its HPC solution (Xeon Phi).

This is the current trend, and with good reasons, since having a shared address space brings a lot of advantages.

Yes, I'm well aware of IOMMUs, and would love to use a common address space for both the CPU & GPU. I am a graphics driver developer, you know.

Hans

Last edited by Hans on 31-May-2017 at 06:31 AM.

_________________
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
Profile     Report this post  
cdimauro 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 6:08:45
#54 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2257
From: Germany

@Hans

I think we're essentially aligned. But let me clarify something.
Quote:

Hans wrote:
@cdimauro

I already covered the adjustable aperture size in my footnote. The standard default aperture size is 256 MiB.

I've read it, and I wasn't referring to this feature, but specifically to the Aperture size, which can be greater than 256MB on PCs.
Quote:
Not really. As a general rule, you don't want the CPU accessing VRAM directly. Instead, data is copied to/from VRAM using DMA and GART (which is more of an IOMMU these days). The GPU's DMA engines can access all RAM and VRAM irrespective of the PCI aperture.

The one reason you want full VRAM to be visible via the PCI aperture is so that there is one physical address space (i.e., the CPU and GPU use the same addresses for everything). That simplifies managing everything.

Exactly.
Quote:
Yes, using GART & the GPU's DMA engine is still on the longer-term to-do list for AmigaOS. So for us the transfers are still on the slow side at the moment. However, once you have your gigabytes of textures and vertices in VRAM, the GPU will access them at full speed.

OK
Quote:
Here's how it works. 2GB of RAM is fully available, because the VRAM's 256 MiB PCI aperture is in the upper half of the available 32-bit 4 GiB address space. So, no sacrifice of RAM necessary.

What about all that extra VRAM? In AmigaOS' case, Picasso96 only knows how to use the first 256 MiB. The rest of the graphics card's VRAM will be managed by the RadeonHD_RM.resource. So, 3D drivers will be able to allocate parts of the additional space, and copy data to/from it. The data transfer is managed by the driver, so app developers don't have to worry about how. No remapping or banking will be performed.

Where is this extra VRAM in the CPU's address space? Nowhere; it's in the GPU's address space, and is managed as such. So yes, we'll eventually be able to us 8GiB+ VRAM despite having a 32-bit OS... once I've written the necessary code.

Thanks for the clarification. This is the normal mechanism used by o.ses from long time.
Quote:
Surely you agree that it is a little crazy plugging a graphics card with 8 GiB of VRAM into your AmigaOS machine when it can currently only use 256 MiB, right? Once the drivers enable using all VRAM it'll be different.

Nothing to contest here: I've already said the for the AmigaOS-/like machine the situation is different from the PCs.
Quote:
Ironically, my post was to counter your claims about large amounts of VRAM and memory banking. I'm glad you've conceded that this isn't necessary.

Well, I'm not as bad as I can appear. I have no problems regretting when I make mistakes.

I'm a human being...
Quote:
I know of at least one AmigaOS user with a >=4 GiB card, BTW.

OK.
Quote:
Yes, I'm well aware of IOMMUs, and would love to use a common address space for both the CPU & GPU. I am a graphics driver developer, you know.

Hans

Yes, I know. And as a GPU developer (not me!) I can imagine that you would like to have both a common physical and virtual address spaces for CPUs and GPUs. But the current situation doesn't allow it.

Cesare

 Status: Offline
Profile     Report this post  
cdimauro 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 6:13:32
#55 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2257
From: Germany

@Hyperionmp

Quote:

Hyperionmp wrote:
@Hans

Interesting read and set of facts. Coming from you, I have no doubt they are accurate as you are actually one of the few people in the world outside AMD who actually develops drivers for these cards.

But as per usual the facts won't bother some individuals.

"Alternative facts" seems to be all the rage these days and not just in the US, sadly.

Ben, please don't speak about questions that you clearly not even (can) understand.

I'm quite aligned with Hans, as you can see. There was only one thing which I wasn't aware, because I didn't know how OS4 implemented the CPU-GPU interface. The rest was a pleasant discussion, because I like talking of (very) technical things.

So, relax.

@Hyperionmp

Quote:

Hyperionmp wrote:
Hands up who has an American passport?

Not me!

I've one.

 Status: Offline
Profile     Report this post  
tlosm 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 7:56:00
#56 ]
Elite Member
Joined: 28-Jul-2012
Posts: 2721
From: Amiga land

@Hans

on linux and linux ppc64 the 256Mb are called by the dri as Bar.
my gpu R7 250 with 2G are view as
2Gb vram, 2gb gart, 256Mb Bar.

is need to say on linux radeonsi dont have acceleration because egl_radeonsi crashes on Be...
on amigaos it is working

Last edited by tlosm on 31-May-2017 at 07:58 AM.
Last edited by tlosm on 31-May-2017 at 07:57 AM.

_________________
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
Profile     Report this post  
kas1e 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 8:23:13
#57 ]
Elite Member
Joined: 11-Jan-2004
Posts: 3487
From: Russia

@Hans
From OS side, how it will looks like when VRAM allocator will be done ? I mean, for now we have 256 mb visibly from OS, which taken by anythng - screens, workbench, all that stuff. So, once we run game which want let's say 512mb of video memory, will it firstly grab from 256 mb from OS (so fill it fully => make things in whole os be slower), and only then grab VRAM memory , or , instead, it will not touch at all those 256 mb visibly from OS, and will all the time grab necessary stuff from VRAM firstly, and only after vram ends, give a go at 256 cpu ones ? Later imho best case for os4 ?



Last edited by kas1e on 31-May-2017 at 08:24 AM.

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

 Status: Offline
Profile     Report this post  
Hans 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 9:03:06
#58 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4927
From: New Zealand

@kas1e

Quote:

kas1e wrote:
@Hans
From OS side, how it will looks like when VRAM allocator will be done ? I mean, for now we have 256 mb visibly from OS, which taken by anythng - screens, workbench, all that stuff. So, once we run game which want let's say 512mb of video memory, will it firstly grab from 256 mb from OS (so fill it fully => make things in whole os be slower), and only then grab VRAM memory , or , instead, it will not touch at all those 256 mb visibly from OS, and will all the time grab necessary stuff from VRAM firstly, and only after vram ends, give a go at 256 cpu ones ? Later imho best case for os4 ?

That depends what the allocated buffer will be used for. Buffers that are uploaded once and then accessed by the GPU only will be put in the extra VRAM immediately (e.g., so most textures & VBOs). Buffers that the CPU will access more often will go into CPU-accessible VRAM. The intended usage is indicated when buffers are allocated.

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
Profile     Report this post  
Nicsoft 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 11:42:33
#59 ]
Regular Member
Joined: 5-Sep-2004
Posts: 235
From: Sweden

@Hyperionmp

Quote:
"Alternative facts" seems to be all the rage these days and not just in the US, sadly.


I think you'd better be careful using that sentence! The White House owns the rights...

1. Kellyanne Conway is the protagonist.
2. Sean Spicer is the director.
3. Donald Trump is the producer.

 Status: Offline
Profile     Report this post  
kas1e 
Re: AmigaOneX5000 Review
Posted on 31-May-2017 13:28:23
#60 ]
Elite Member
Joined: 11-Jan-2004
Posts: 3487
From: Russia

@Hans
Quote:

That depends what the allocated buffer will be used for. Buffers that are uploaded once and then accessed by the GPU only will be put in the extra VRAM immediately (e.g., so most textures & VBOs). Buffers that the CPU will access more often will go into CPU-accessible VRAM. The intended usage is indicated when buffers are allocated.


Sadly that there is room for "ifs" :) I mean, from pure game-port-from-linux perpective, will that new allocator help to avoid situation when we have filled from 256 mb accesed by cpu, and so everything going to be slow and crawl ?:) Or, there will be "to be seen", as well as there may be needs for some adaptation code ?


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

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 Next Page )

[ 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