Where does all this leave Bitboys?

[Geeforcer]

Now that we have P10 and Parhelia as examples of things to come I am particularly interested in three emerging trends and their effect of viability of Bitboys design particularly interesting.

Looking at the two aforementioned chips, we see that already hefty transistor counts become heftier still, increasing past 70 million mark; increase in on-board memory to 256MB to accommodate increased consumption by high resolution and anti-aliasing (amongst other things) and lastly, the emergence of 256 Bit bus.


With transistor counts so high, viability of additional tens of million transistors required for EDRAM seem quite low, as it would push transistor count past 90 and maybe even past 100 million.
As framebuffer size increases, will 12MB EDRAM be enough? For comparison, the amount of RAM on high-end video cards has increased four-fold in the last 2 years. (From 64MB on Geforce 1 cards to 256 MB on the upcoming products).
This fall, a combination of 256 bit bus and 400MHz DDR RAM will provide bandwidth of 25.6GB/s, greatly decreasing (albeit not eliminating) XBA bandwidth advantage, which incidentally happens to be the main selling point of the whole architecture.

[MfA]

Hasnt it been mostly established that the 12 MB avalanche part even if it did show up would just be used as a proof of concept not a product?

The problem with XBA is that it need very high fillrate to justify itself, with the old rather simple rasterizers of pre-DX8 that might have been possible ... but with PS2.0 its unlikely to be possible (shadow buffers could really use a rasterizer capable of a very fast rasterization of simple pixels though) pixel shaders are going to take way too much area ... fillrate will likely stagnate for a while, removing some of the bandwith pressure (this is only an issue for eDRAM, not for a tiler which doesnt need to give up chip area for bandwith).

Embedded memory in the amounts needed for a 3D chip with an embedded framebuffer would have been usefull in a very small window, and Bitboy's missed it ... large amounts of embedded memory will have to wait a couple more years, till thin film memory is available in the foundries (with these memory can just be stacked on top of the logic, very cheaply at that ... making the bandwith gains pretty much irresistible).

[Geeforcer]

Embedded memory in the amounts needed for a 3D chip with an embedded framebuffer would have been usefull in a very small window, and Bitboy's missed it ...

That was my point as well, although I forgot to spell it out :oops:

[Tahir2]

"Where does this leave Bitboys?"

Exactly where they have been for many years... Findland.. sorry I meant Finland

[Typedef Enum]

Honestly...It's not as if any of these announcements/tech's have directly hurt BitBoys. BitBoys, themselves, have hurt themselves because they had an extremely tiny window in which to execute...IF they were ever to succeed in this market. That window has since closed.

I think it's safe to say that those fellas @ BitBoys should honestly consider calling it a day, and send their resumes to the likes of Matrox/ATI/nVidia.

If these guys manage to get additional financing (and I know we've said this countless times now), I would really be in shock...I just cannot see how they can possibly stay afloat, given a complete/total lack of $$ going back into the Company from anything close to a retail product.

[noko]

Embedded memory in the amounts needed for a 3D chip with an embedded framebuffer would have been usefull in a very small window, and Bitboy's missed it ...

Ahmmm, how about console usage where most graphic chips end up in?? Still seems viable to me, maybe MS could use such as design in Xbox2 if that will happen. Just a thought.

[MfA]

Well yes, by the virtue of the smaller framebuffers it does make sense even at the moment (if you have access to a good eDRAM process, IMO both Nintendo and Sony had to make too many compromises). But it will take another 3 years to the next gen, so who cares? :)

[Geeforcer]

(I actually would much prefer to focus on technology then on the company itself, since that has already been discussed hundreds of times.)

To continue my line of thought: Let us assume that Bitboys were to finally release a card this fall. I think we all can agree that in order to be successful any high-end card will have to be DX8-complinet at the very least.

Using GF3/4 + Radeon 8500 as example, a full-featured DX8 chip is ~60 million transistors, give or take a few million. Let us also assume that Bitboys would use at least 12MB of 1T-DRAM, which would require an absolute minimum of 100.6 million transistors (!), resulting in the total transistor count of 160 million (again, this is an absolute minimum). Considering that the Infienon smallest eDRAM manufacturing process is 0.17µm, the likelihood of Bitboys providing an DX8-complient, XBA-based solution in the near future is equal to 0.

[Nappe1]

there is at least your way and their way to see their situation at the moment. Of course transistor counts have increased heavily and so is their work-a-load.

fact is no one really exactly knows outside the company what they have been doing during last year and a half. there is some "funny" rumours flying around...

but I'll drop this subject until Boys themselves have publically said something.

[BenM]

It would seem to me that Parhelia and P10 leave BitBoys with the task of working on their resumes. :lol: :wink:

Assuming that Nvidia and ATI move to 256 bit memory connections by fall 2003, combined with advanced HyperZ/LMA, BitBoys has no advantage at all. IMHO, of course.

[Typedef Enum]

It would seem to me that Parhelia and P10 leave BitBoys with the task of working on their resumes.

hehe...My feelings exactly :)

[CoolAsAMoose]

If these guys manage to get additional financing (and I know we've said this countless times now), I would really be in shock...I just cannot see how they can possibly stay afloat, given a complete/total lack of $$ going back into the Company from anything close to a retail product.

One reason they continue to get new financing could be that they have really been able to show working hardware, hardware that really showed the potential of their architecture. Don't blame them 'cause they're quite!


Using GF3/4 + Radeon 8500 as example, a full-featured DX8 chip is ~60 million transistors, give or take a few million. Let us also assume that Bitboys would use at least 12MB of 1T-DRAM, which would require an absolute minimum of 100.6 million transistors (!), resulting in the total transistor count of 160 million (again, this is an absolute minimum).

I would guess that of the 60 million transistors, a fairly large part is already memory in the form of different caches (SRAM). Using eDRAM could lower the need for caches. Bitboys have earlier stated that (the logic of) their architecture needs less gates then the competitors. IIRC, Glaze3D was said to use 6 million transistors for the logic.

In most cases, when using eDRAM, I believe the manufacturing process is different, less optimized. With 1T-SRAM, though, I think I read that it can be implemented on an ordinary logic-process. So using a 0.13 um process I do believe that 12 MB 1T-SRAM (if it can be used) could be reached. Remember that memory in general consumes less space on the core compared to logic.

The whole cost/bandwidth-question is: what is most expensive, using 12 MB of eDRAM together with a medium-fast 128 bit external bus, or skipping eDRAM and implement a super-fast 256 bit external bus?


I am, as most of you, pessimistic about Bitboys coming out with a top-class product (or any product at all). But them being quite doesn't automatically mean they are in financial or technical trouble. It seems Matrox and 3DLabs may come back big-times now. So why couldn't Bitboys.........

[Typedef Enum]

It seems Matrox and 3DLabs may come back big-times now. So why couldn't Bitboys.........

In order to "come back," wouldn't it be required for you to have actually been somewhere near the top...at some point?

At no time has the BB's ever approached that point...At some juncture in their existance, they have to deliver...It's utterly ridiculous to continually launch newer roadmaps/web-analysis/PR/etc. when one fails to get a single product to the market.

As I said before, I wonder how long it will take the BB's to update that image showing the XBA bandwidth advantage over the GF3/etc. They now have to account for Parhelia/P10...and soon enough, NV30 and R300.

[LeStoffer]

I think that SA said it best when he was commenting on the P10:

As I mentioned earlier, the chips coming out in the DX9 time frame should all have enough memory bandwidth to meet their needs. When it comes to transistor count though; well that's another story. An end-to-end floating point pipeline takes a lot of transistors. The companies that come up with creative ways to significantly increase their total transistor count over their competitors will have the leading edge as the competition heats up.

In other words: Using your given transitor amount/die real estate for EDRAM seems to be the wrong way to go with a DX9-part right now. IMHO.

[Joe DeFuria]

Given the transistor / bandwidth assumption we're making for DX9, it will be interesting to see if the upcoming DX9 parts can distance themselves, performance wise, from their high-end DX8 ancestors when running DX8 and lower apps.

The big question mark, IMO, is Doom3. No one can underestimate the "selling power" that Doom3 will have. The card(s) that excel in "Doom3 Demo1" test will have a huge advantage.

So it will be interesting to see if :

1) Carmack writes specific code paths for the DX9 parts to take advantage of the (assumed) increased flexibility of their pixel pipelines. I'm pretty confident that if the initial Doom release doesn't include specific support, he will later include it with a patch if for nothing else than to give him experience with the new pipelines. (This is assuming, of course, that the DX9 vendors include support for their new pipelines with GL extensions.)

2) That the increased DX9 flexibility does in fact lead to, clock for clock, an increase in performance over DX8 code paths.

If Doom3 fails to show any significant performance improvement on DX9 class hardware vs DX8 hardware, selling these new DX9 parts might be a hard sell if they command a price premium.

[MfA]

Hell, if you only cared about DoomIII you could probably build a faster DX8 part than any DX9 part could ever be with the same transistor count.

[Geeforcer]

I would guess that of the 60 million transistors, a fairly large part is already memory in the form of different caches (SRAM). Using eDRAM could lower the need for caches. Bitboys have earlier stated that (the logic of) their architecture needs less gates then the competitors. IIRC, Glaze3D was said to use 6 million transistors for the logic.

In most cases, when using eDRAM, I believe the manufacturing process is different, less optimized. With 1T-SRAM, though, I think I read that it can be implemented on an ordinary logic-process. So using a 0.13 um process I do believe that 12 MB 1T-SRAM (if it can be used) could be reached. Remember that memory in general consumes less space on the core compared to logic.

The whole cost/bandwidth-question is: what is most expensive, using 12 MB of eDRAM together with a medium-fast 128 bit external bus, or skipping eDRAM and implement a super-fast 256 bit external bus?


I am, as most of you, pessimistic about Bitboys coming out with a top-class product (or any product at all). But them being quite doesn't automatically mean they are in financial or technical trouble. It seems Matrox and 3DLabs may come back big-times now. So why couldn't Bitboys.........

As far as I know, total amount of cache on Geforce 3 goes not exceed 200KB. However even assuming that the cache accounts for one-third or the total transistor budget, it will still be some 40 million transistors, and that is for DX8 compatibility only.

Regarding the 6 million number: First, I believe it was 6 million gates (12 million transistors). Second, that was a long time ago, before HWTL, let alone DX8.

12MB of 1T-DRAM (Regarding so-called 1T-SRAM - see this article (http://www.atmoscorp.com/news_and_events/media_coverage_view.php?id=25)) would require huge amount of transistors: 1 transistor per bit, 8 per byte, 8,388,608 per Megabyte and 100,663,296 per 12MB. (I am not sure whether a parity-check would be used, but in that event transitory count would increase even further). Considering that the most advanced manufacturing process that Batboys manufacturing prater (Infienon) has is 0.17µm, I don't see how Bitboys could realize their XBA design in the near future unless they either find another partner with 0.13µm process, decrease the amount of embedded RAM, sacrifice DX* compliancy or do more likely, do all of the above, thus severely reducing their chances for market success.

[Joe DeFuria]

Hell, if you only cared about DoomIII you could probably build a faster DX8 part than any DX9 part could ever be with the same transistor count.

Exactly. So the question is, will a DX9 part with the transistor budget of 0.13, offer enough "DX8 / Doom3" pixel power to be competitive with a DX8 pipeline chip at 0.15 microns?

[Nappe1]

Hell, if you only cared about DoomIII you could probably build a faster DX8 part than any DX9 part could ever be with the same transistor count.

Exactly. So the question is, will a DX9 part with the transistor budget of 0.13, offer enough "DX8 / Doom3" pixel power to be competitive with a DX8 pipeline chip at 0.15 microns?

Joe: I am thinking the same thing...

and about Bitboys, I would love to share my opinion, but I just can't. doing that I would be making more harm than good for them.

[CoolAsAMoose]

12MB of 1T-DRAM (Regarding so-called 1T-SRAM - see this article) would require huge amount of transistors: 1 transistor per bit, 8 per byte, 8,388,608 per Megabyte and 100,663,296 per 12MB. (I am not sure whether a parity-check would be used, but in that event transitory count would increase even further). Considering that the most advanced manufacturing process that Batboys manufacturing prater (Infienon) has is 0.17µm, I don't see how Bitboys could realize their XBA design in the near future unless they either find another partner with 0.13µm process, decrease the amount of embedded RAM, sacrifice DX* compliancy or do more likely, do all of the above, thus severely reducing their chances for market success.

I thought the Infineon partnership was off, but maybe that was just a rumour. That was the reason for me looking to MoSys 1T-SRAM and the possibility to be used in the same TMSC 0.13 um process that NVidia and ATI will use. This is what I found on MoSys page: "1T-SRAM architecture allows the use of standard logic manufacturing processes without requiring any process changes".

With regards to the article linked to, is basically says 1T-SRAM = 1T-DRAM. But this is at least not MoSys view. They claim 1T-SRAM have a lot of the characteristics of normal SRAM: "1T-SRAM technology also offers the familiar, refresh-free interface and high performance for random address access cycles associated with traditional SRAMs".

And about lots of eDRAM:
Didn't Sony produce the GS-32 (32 MB eDRAM) for the GSCube on a 0.18 um process? Of course, that chip was huge, and prolly really expensive.

So I do believe that 12 MB together with a fairly modern 3D-core should be reachable. But I do agree with the problem that 12 MB might not be enough with todays expectations of high resolutions. The eDRAM could be used for Z-buffer, but the Z-buffer B/W problem is probably cheaper to solve with some occlusion culling hardware. So what about putting the frame-buffer in eDRAM, but Z in external memory then? Well, at high resolutions, with AA, 12 MB will not be enough (or?). That leaves the NGC Flipper aproach: use eDRAM for the backbuffer, and then copy the frame to the front buffer in external memory. Don't really like that!

To sum it up: 12 MB is either too much or too little.

[MfA]

I wouldnt be surprised if TSMC's 1T-SRAM cell's at .13u were just as large as Infineon's eDRAM at .21 BTW. Im pretty sure Sony has access to a real eDRAM process too.

[arjan de lumens]

Hmm ... the main problem with the avalanche architecture the way I see it is that 12 MB of eDRAM is not nearly enough to be useful in the situations where large amounts of bandwidth is really needed today: High-Resolution Anti-Aliasing. At, say, 1024x768, with 4X AA and 32-bit frame/Z, it isn't even big enough to hold the Z-buffer, much less the framebuffer. This gets even worse with 64-bit color.

If BitBoys wants to make a product that can beat, say, the Parhelia or P10, across the board, I'd say that they need at least 30 MB of eDRAM (for a 4x Z-buffer or compressed frame/z-buffers at 1600x1200), a 256-bit bus (which only requires a very large pin-count, thus forcing a huge total chip area without taking very much chip space itself, and should thus be a good match to eDRAM!) and at least 8 pixel pipelines.

[arjan de lumens]

AFAIK, 1T-SRAM, with all its latency optimizations, has about 2-3 times the cell size of regular eDRAM on most logic processes (about 1 um^2 vs about 0.3 um^2 at TSMC/UMC 0.13 micron). Which makes it sort of unsuitable for Bitboys-type applications.

[Geeforcer]

To sum it up: 12 MB is either too much or too little.

I agree. But if they were to increase it to 24-36MB, the transistor count would become too large for chips to be produced economically even at 0.13µm, forcing them to wait for a more advanced process - and in the meantime the memory requirements would increase even further. Vicious cycle?

Regarding GC with large amounts of eDRAM - I remember hearing that each of these chips had around 300M transistors, with prices pushing $1000 per chip.

[arjan de lumens]

Regarding GC with large amounts of eDRAM - I remember hearing that each of these chips had around 300M transistors, with prices pushing $1000 per chip.

Sorta wonder - what makes eDRAMs so incredibly expensive compared to discrete DRAMs? Especially considering that you can buy a 256MB ddr dimm module (that's 2 billion transistors) for something like $27?

[ERP]

My understanding is that EDRAM is put down in a two stage process, First the Ram is masked on with a DRAM process, then a standard process is used on the rest of the silicon.
This has to really hurt yield which in the end dictates cost.

[Panajev2001a]

Arjian, look at that DIMM and see how many chips you have... when you talk about a single chip with that much e-DRAM in it you have to imagine all that space, all those macros put together... the chip becomes huge, the amount of verification and testing increases and the yelds go down... etc... etc...

[arjan de lumens]

OK - that would be typically 8 chips on the DIMM - 256 MB/8 = 256 Mbit = ~270 million transistors per chip @ 27/8 = 3.38 dollars per chip.

Which is a factor of ~300 lower than the GScube chip, with the same amount of DRAM and nearly the same amount of transistors. So what is going on?

Guesswork: If we assume that the DIMM is sold at 1/3 of production cost (which tends to happen for the stuff you find on pricewatch), that eDRAM takes, say, twice the chip area per bit over discrete DRAMs, that production becomes twice as expensive per area unit due to added manufacturing steps, and that half of the chip is something else than eDRAM, we end up at $80 cost per chip (still with 32 MB DRAM on the chip), not counting the effects of yield. A $1000 price per chip would then imply a yield of ~8-10%, compared to the >99% that is normally reported for discrete DRAMs of all sizes. Hmm...

[Basic]

DRAM-transistors are much smaller than logic transistors, so just adding them to get a total size of the chip is meaningless. And the latest public incarnation of their specs is actually talking about 12MB eDRAM.

1T-SRAM is however larger than DRAM, and I believe larger than eDRAM too. I don't remember by how much though. But it's still a lot smaller than 1bit per logic transistor. The reason for it being larger is that it has got more stuff around the actual memory array.


And here I were about to write something about the term 1T-DRAM. But thank god I did some searching first. Almost made a fool out of myself. :)
The article Geeforcer pointed to doesn't seem to be correct. Or more precisely, does not reflect all (not the new) uses of the term 1T-DRAM.

1T-SRAM is a memory that uses ordinary DRAM cells for storage. But it's arranged in many small banks, making it as fast as a SRAM. And it's coupled with a clever caching mechanism that completely hides refreshes. Result is a memory that behaves like a SRAM.

1T-DRAM can be used to say two things. It has been used to say how many transistors a DRAM cell is using. I've seen 1T-, 3T- and 4T-DRAM cells, where a 1T cell would be bog standard.
But it can also mean "one transistor" as opposed to "one transistor and one capacitor". Then it suddenly means a rather new method where the capacitor size is drastically reduced (parasitic instead of explicit capacitance). It halfs the size of the DRAM cell, and makes it possible to do it in a logic process (with SOI). - Very interesting indeed.

But none of these meanings can be used to cathegorize 1T-SRAM since they refer to the memory at cell- (or micro-) level, instead of architecture- (or macro-) level.

[Edit]
As you might understand from lack of context; there has come quite a lot of new posts here since I started writing this post. :)

[kl899]

can someone please explain this "thin memory" that someone mentioned that can be stacked on top of the chip logic? how much bandwidth could it offer?

[MfA]

Thin film, anyway see these sites :

http://www.ovonyx.com/
http://www.thinfilm.se/

(For both Intel will have very favourable licensing terms if they work out BTW)

[Basic]

arjan:

DRAM and eDRAM isn't made on the same process, so you can't compare them directly. DRAM cells are small since the process is optimized to make capacitances lagre. But a logic process is optimized in the opposite direction, meaning that eDRAM cells in such a process must be made larger. Normally you have to do some kind of compromize for an eDRAM process.

I think that DRAMs are usually done in smaller processes than logic (and eDRAM). And the reason for that being that DRAMs are such a static and repetitive design that they can do better optimizations. The huge volumes also helps to get the process trimmed.

DRAM uses fewer metal layers than logic (and eDRAM). More metal layers means lower yield.

[linthat22]

Sorry guys, but I still think when they release their chip it'll kick all forms of ass :wink:

[arjan de lumens]

Some quick web searching on DRAM vs eDRAM processes finds this: The latest (http://www.semiconductor.com/company/announcements/2002/6228_nr_20020513.shtml) available discrete DRAMs are manufactured on a 0.15 micron process, with a cell size of 0.176 um^2, which is slightly more than half of the 0.31 um^2 eDRAM cell size that UMC offers on its 0.13 micron logic process.

While it is well known that combining DRAM and logic in the same chip reduces the yield of the logic portion of the chip, attaining >99% yield for the eDRAM portion of the chip is trivially (http://www.ee.ualberta.ca/~elliott/memory/conferences/1999dft_wickman_fm.pdf) easy, so the total design yield should be essentially independent of eDRAM size. Which is why I find the $1000 cost of the GSCube chip weird, even despite its huge size.

[CoolAsAMoose]

Interesting link about an optimized 1T-DRAM cell for eDRAM:

http://www.eetimes.com/story/OEG20020510S0065

[arjan de lumens]

:o

That 1T-DRAM looks really interesting:
Half the cell size of traditional eDRAMs
Implementable in pure logic processes with Zero extra processing steps = no yield reduction
Nondestructive reads = substantially reduced memory latency for page breaks
Requires SOI, though.

[Panajev2001a]

Arjian, 32 MB of e-DRAM means a relaly huge die... plus what if they used just a .18u process ? Yelds would have been poor, wouldn't they?
Also are you sure that's the price foa single GS chip and not for the GScube blade ( 16 blades with EE and GS-32 ) ?

I don';t understand what you mean here

"While it is well known that combining DRAM and logic in the same chip reduces the yield of the logic portion of the chip, attaining >99% yield for the eDRAM portion of the chip is trivially easy, so the total design yield should be essentially independent of eDRAM size."

e-DRAM size determines how big the ship will be assumed standard transistor count for the rest of the GPU's logic...


BTW, abotu the 1-T DRAM... remeber Sony has access to IBM's .10u SOI process ( with copper interconnects )

[arjan de lumens]

Arjian, 32 MB of e-DRAM means a relaly huge die... plus what if they used just a .18u process ? Yelds would have been poor, wouldn't they?
Not necessarily - see below.

Also are you sure that's the price foa single GS chip and not for the GScube blade ( 16 blades with EE and GS-32 ) ?

I was just assuming that the number that Geeforcer gave was correct.

I don';t understand what you mean here

"While it is well known that combining DRAM and logic in the same chip reduces the yield of the logic portion of the chip, attaining >99% yield for the eDRAM portion of the chip is trivially easy, so the total design yield should be essentially independent of eDRAM size."

e-DRAM size determines how big the ship will be assumed standard transistor count for the rest of the GPU's logic...

My point was that when you have a large DRAM array, you can use techniques like redundant colummns, ECC, etc. to make the DRAM as fault-tolerant as you like, to the point where essentially no matter how many defects the DRAM array contains (even several hundreds), the DRAM still remains perfectly usable. (This, of course, applies in exact the same way for any kind of eDRAM as well.) With such techniques, you can throw an essentially arbitrarily large amount of eDRAM onto a chip design, and its yield just won't change, even if the chip gets physically very large. (Of course, without these techniques, you will get piss-poor yields for any design with more than a few megs of eDRAM)

[CoolAsAMoose]

Maybe this has been discussed before..... anyway,
I found a MoSys presentation describing the organisation of the 3 MB 1T-SRAM integrated on the NGC Flipper.

http://www.mosys.com/news/ipj2k1.pdf
Flipper part starts at page 28

The chip is 110 m2 on NECs 0.18 um eDRAM process, and I have read elsewhere that it consists of 51 million transistors.

Frame/Z-buffer
==========
* 4 independant macros of 4 MBits, total 16 MBits (2 MB)
* 96-bit wide input and output for each macro, total 384 bits
* Sustained 9.6 GB/s bandwidth for random accesses TO ANY ADDRESS
* Sustained latency of under 5 ns

Texture buffer
=========
* 32 independant macros of 256 kbits, total 8 Mbits (1 MB)
* 16-bit wide input and output for each macro, total 512 bits
* Sustained 12.8 GB/s bandwidth for random accesses TO ANY ADDRESS
* Sustained latency of under 5 ns

[Gunhead]

110 m2, that's bigger than my flat. And what's "independAnt"?

[Asshole day.]

[CoolAsAMoose]

Doh, 110 m2......... yeah thats a big chip. My misstake!

So I been away a while but Im back and ready to comment on the BB thing....

well actually I can be very brief about that one.........

You have to wait until they make the anouncement........which will be in the near feature.......

:o

[mech]

If you used multi-sampling FSAA you'd only need to store 4x Z-Buffer and the frame-buffer. You'd still need at least 16MB RAM to just do 1024x768x32. Not worth it.

[Jerry Cornelius]

Maybe they are going to use a memory paging system, and aren't going to embed nearly as much RAM as everyone is thinking. A 32 MB backup frame/Z buffer running off of a dedicated cheap-ass bus may do the trick.

What you get:
-texturing and other operations don't have to compete with frame/Z buffer access for bandwidth.
-nearly unlimited frame/Z buffer access (as long as the paging system can keep up)

Just a thought

[arjan de lumens]

Memory paging is mostly useful for texture data, as often a lot of texture data remains untouched during the rendering of a scene and can thus be swapped in/out as needed at little efficiency loss. With the framebuffer and Z-buffer, though, you almost always have that every single byte of these buffers is accessed during rendering of every frame, often several times. So a framebuffer paging system would likely end up going totally swap swap swap, overloading even wide memory buses.

[MfA]

Unless you use tiling (which is not tied at the hip with deferred shading how ever many times thats repeated).

[Typedef Enum]

You have to wait until they make the anouncement........which will be in the near feature.......

No offense...But, I hope you realize just how redundant such a statement is...

If we were talking about ATI/nVidia, that would be different...But if we're dealing with the BitBoys, it becomes slapstick-like. How many times have people been setup for failure with statements like, "Man, just wait!" or "Dude, this thing will destroy everything..." etc. etc.

Even if the BitBoys had a paper launch (similar to Parhelia) tomorrow, I would honestly take it with a huge grain of salt...even if they had silicon. Why? Because, I would still have huge reservations about the production end of things.

[Nappe1]

TypeDef Enum: so, if someone is willing to believe to them and accidentally says something positive about them or timelines, are you forced to answer to it? ;) (no offence ment in any form.)

I mean that everyone answering to "they will deliver" -message with "I don't believe it ever" -message gets fanaticts answer to that one and so on... So, every post aimed against "they will deliver" fanatics will actually Increase the hype, instead of reducing it.

I _know_ that this conversation has centered to dull side of the coin, but I am not willing to discuss _ANY_ timelines or projects conserning Bitboys or their products.

It is really up to them. I know almost damn too well what's the situation there, but atm, there is no use of this kind of discussion.
Before that, everything around Bitboys is pure speculation.

[Typedef Enum]

No offense taken...

All I'm saying is that...if I had a dollar for every "just wait..." comment (to include my own statements some time ago), I would have a fairly healthy chunk of change in my pockets by now...