I mentioned in this in a prevous post last summer (/. isn't working correctly now and I can't pull up the link, so if you can browse my user posts, it's in there somewhere)
So far I've got the compositing of windows down, windows are displayed hierarchicly and can be composited with any of the gl blend functions, and any arbitrary gl rotation matrix (my switch desktops routeinis going to look somewhat like you're entering hyperspace in the Falcon, cheesey and unnecessary, yes, but definately has a high WOW factor.
The communciation is over pipes and it is very fast, no problems there.
The selection mechanism works great, I just render the window ids to the backbuffer and use glReadPixels to get the id and send window events to the clients. The events I send are just like xlib (no Expose events, though!!:D), so far I send enter/leave notify, button press/release, motion notify... windows default to a button grabbing mode and can pass grabs onto other windows, implimenting a popup menu system in a tk should be trivial.
Currently I'm just about to impliment the font selection/drawing scheme (arbitrarily scaled/rotated fonts, resolution independence so you can have nice sized, crispy fonts, and possibly use hw routines to aid in anti-aliasing).
So that's where the project stands. The programming model is similar to X w/o a lot of the cruft. Did I mention it's really fast? Hopefully I'll have a demo out on sourceforge soon, this is NOT vapor...
Has anyone been able to get the ATI fglrx drivers to build with a 2.6-test kernel? That's the only thing stopping me from using it, I've been drooling over the CPU throttling and other ACPI features for some time now, but I can't do w/o my crazy-fast OpenGL either!
Screen quality is measured by contrast, brightness, pixel responsiveness and quality of the glass
The HP/Compaq WUXGA's brightness is one of it's best qualities, along with another trait that you didn't mention for LCDs -- wide angle viewing. The X1000s at CompUSA & Best Buy have the lower end displays, you have to custom order to get a WUXGA model (but I believe they do carry the 1680x1xxx). Anyways, this display is far superior to the apple 15.2. The first comment I get about it is usually "that is the clearest picture I've ever seen". Watching anomorphic dvds on it is amazing!
Oh, and I've made it a Lintel laptop, not Wintel;) Still waiting on damned centrino wifi, though. The pentium-M core is pretty sweet, too. Long battery life, doesn't get hot in my lap, and has plenty of processing power when called upon, helped out by the 1MB on-die L2.
Oh, and another thing, the screen is excellent. Probably the best laptop screen I've seen
I guess you haven't seen the WUXGA screens now shipping on HP/Compaq nx7000/x1000 or Dell's widescreen laptops. 1920x1200 resolution, 15.2 diagonal. I can't believe that Apple hasn't shipped a better screen than 1280x854 on it's 15 inch model. My 15.2inch HP has more pixels than the 17inch Powerbook! The picture is amazing. As a side note, the company that makes the Powerbooks for Apple (Compal), is the same one that makes those HP/Compaq notebooks, so I was half expecting 1920x1200 on the new Powerbook, what a let down...
First, what a great idea. Congrats to these guys, as long as they aren't compromising anyone's privacy...
The only songs I download are singles I hear off the radio and want to listen to a little more before purchase. The RIAA could profit off of this if they wouldn't make a cd single cost $8.99 (what bull!). Just sell them in cheap paper/plastic cases (like most pee-cee games, once you get them out of the enormous box, hehe, enormous box...) If only SOMEONE would come up with a way to profit off of cheap, highly available music singles *sigh*
I don't know exactly what the law is about this, but I've never got phone spam on my cell. Lately it's cheaper than the local telco and I get long distance, and the obvious handiness of being mobile. Plus now friends & fam only have to remember one number for me. If I ever do get an unsolicited call, my planned response is "f**k you, this is a cell phone, *snap*". Can anyone enlighten me as to the laws on unsolicited calls to cell numbers? Are they just filtered by service providers?
I got my start by doing a GUI tk & wm for X, got sick of X, and just started this OpenGL thing a couple months ago. I had the idea for an OpenGL display server a few years back when I was at SGI, and now I'm finally doing it;) email me mike-d@mike-d.org if you're interested.
My implementation doesn't use pbuffers/GLXPixmaps, etc. I'm using textures. The "MakeCurrent" functions are very costly in terms of speed, as is swapbuffers.
So, how am I using them? Every window has a front/back texture. The front texture always contains the most current composited version of the window, the back texture is used for drawing operations. When a texture is not resident, these live in unsigned char buffers in main mem ( haven't gotten to the whole memory management stage yet ). Anyways, since the front buffer always contains the current fully composited window, to recomposite the toplevel you only do one textured poly per application.
Now, for fast client side drawing... all off-screen drawing takes place in the toplevel back buffer, which is only swapped when a client wants to update the contents of it's window. Drawing ops first draw with a poly the size of the window with a (GLZERO, GLZERO) blend func, to do a clear (we want to avoid glClear as it is costly). We then draw the current back texture, then do our drawing op. If the server's next drawing op is to the same window, we don't do the clear poly. When another app needs to draw, we read out with CopyTexSubimage. When a client calls "UpdateWindow", the front/back buffers are swapped, and the window is recomposited up the hierarchy, the last step being to draw toplevel windows. This is all very fast, and even older gfx cards (my old quadro) can push enough pixels to have clients draw at nearly 50fps 1024x768.
By way of comparison, using pbuffers/GLXPixmaps and glDraw/ReadPixels and swapping contexts/using MakeCurrent I could only get 4fps (compare that to the Quartz Extreme numbers). I'd love to find people to work on this with me. So far all I've done is test frame rates with the various methods I mentioned, and did a basic client/server framework. Once that's all in place, my toolkit should work well with the new system, and hopefully Qt/gtk;)
I need to try out your Embedded Mesa driver. That's exactly what I want, a driver that is purely GL. Email me at mike-d@mike-d.org.
Cheers, Mike
Re:Sounds like a plan.
on
Qt On DirectFB
·
· Score: 5, Interesting
I've always thought that it would be a good idea to reengineer the whole system from scratch to take advantage of today's hardware and UI concepts.
Good idea, I've thought the same thing. I wrote a GUI toolkit for X, and a window manager, so I've got a good idea of how the whole thing works. I quit working on it as I was frustrated that I couldn't do some of the neat things I see in OS-X on X (that sounds funny, doesn't it?). Soooo...
I started from scratch writing an OpenGL based display server. I'm using a lot of ideas from X, but throwing out a lot of cruft and adding lots of enhancements. All of the drawing is double-buffered -- no more Expose events!!!!:) All of the drawing is also hardware accelerated. I've figured out a way to do this very well, without context switching the gfx hardware. One possible method will allow many clients to draw at once and keep a constant framerate (by not context switching/swapping buffers within a certain timeslice, these are very costly operations).
Some of the ideas I am keeping are the idea of "internalizing" graphics buffers to the server where they can be shared among other applications. I'm also keeping the idea of a replacable window-manager like shell.
For fonts I'm using Freetype. Standard image format is png. The display is also hardware-resolution independent and colordepth independent. Right now I'm being setback by the fact that I can't get X working on my new laptop (anyone know a modeline for WUXGA+ 1920x1200@60Hz, for Compaq X1000?). For communication I'm using named pipes/shared mem.
I'd also like to implement creating server-side macros so a client can pass one command to the server and execute a whole set of drawing routines atomically. Oh, and the source is definately going to be open. Any of this sound like a good/bad idea?
check out the hp-compaq x1000 (www.hpshopping.com) series, they're pretty sweet and dirt cheap. configurable from $1299 w/rebate, up to 1900x12000 WUXGA+, radeon 9200 64MB DDR, 80GB drive, pentium-m 1.6GHz (this processor is sweet, first mobile processor with 1MB _on-die_ L2, to keep it fed with data while maintaining low power usage). I tricked mine out with all this stuff for about $1800. Oh, and a slick mostly-aluminum case. Yes, I know it's a rip off of apple, but it costs some much less for more powerful hardware ( the pentium-m @1.6GHz is comparable to p-4 @2.4, but has around 5hr battery time).
What the author is looking for is described in Neal Stephenson's "The Diamond Age". Basically, all your electronic devices are ready and willing to receive and send packets from/to anyone else's devices (in Stephenson's book the devices are nanotech MEMs of some sort). Your encrypted communications just hop along from one person to the next until they reach their destination. I think it's a wonderful idea. Equip everything from phones to handhelds to t-shirts,etc with the ability to route data. The only tricky part is finding where the source/dest are physically located and then routing. You'd need some sort of positioning system that would be a one time cost+maintainence.
I know I'm not alone with this problem. The flash plugin (or mozilla) does a blocking wait whenever it loads a page that requests sound, so it freezes when I've got an mp3 playing. It's no fun having to stop your music every time some page decides to load flash content. I loathe flash, but unfortunately I sometimes need to view a page that has flash content. Is this a bug in mozilla or flash?
There comes a time when you have to chuck backwards compatibility in the name of progress. The problem is we've got all this existing software that's been tailored for x86. Right now we're experiencing similar problems in the automotive industry, which is much more stodgy than the semiconductor biz. We're stuck with ancient internal combustion behemoths because of people's unwillingness to accept change. Likewise, we're stuck with cpu tech that's relatively much older than our crappy auto tech given the pace of the semiconductor industry.
Let x86 go! Live in the now! Itanium is a great CPU. Sure, the first iteration sucked, but look at it in the same light that you view electric automotive designs. Now take a step back and look at Itanium II. Itanium II is currently the leading performance CPU for floating point code by a small margin over Power 4 ( which, I might add, costs 2-4x more than an Itanium system ). In four months time Intel is said to be releasing a frequency bump to Itanium II with even more L2 cache. IA-64 performance scales almost linearly with frequency! (and no, you don't even have to recompile to reap the benefits of increased frequency) When Dell saw that the Itanium II performance rumours were true, they did a 180 and are now playing catchup to other vendors. IBM has hedged their bets by building Itanium II systems, Sun is dying, and Opteron will be DOA.
Those steps are for someone who doesn't have at least kernel v2.4.20 and the proper modules compiled. Most current distros have all the necessary stuff so you just need to plug it in and mount it. At that point, it's just like any other drive and (like on windows) it's a matter of writing the itunes.db on the ipod. Ephpod is pretty good for this, but it's windows software so requires wine. This is not a permanent solution. Someone will build a nice linux native UI, I'm working on one myself.
my mom had the hardest time installing the software and pluging the darn thing in
I bet she did. For instance, when I plug mine in under winxp as soon as "Musicmatch Jukebox" recognized the iPod the #@!ing computer restarts. I'm not re-installing the (P)OS for this when a kernel compile takes 5 min. I was, however, able to get it to work in windows with ephpod, but all my music is on the linux box anyways and transferrring over the network is slower than firewire. Kudos to the ephpod developers, very nice. Open source it!
Apparently the site is already/.'ed. Here's a way to get it working with a nice GUI.
I'm using the latest stable kernel (2.4.20). 1394/ohci/sbp2 are all working great. Be sure to check "prompt for development drivers", then add the 1394 module and be sure to add OHCI and sbp2 (these also help if you're into dv;). Be sure to have SCSI compiled in or as a module!! Also be sure to inlude the HFS (if you've got the mac version) or msdos/vfat (for windows ipod) if you don't want to reformat your ipod. Reboot with you new kernel.
modprobe the 1394 and ohci modules. Do a tail -f on/var/log/messages and plug in your ipod and wait for the magic:) You should see Apple iPod being added as a (5/10/20)GB SCSI disk. Add a mount point for the drive in/etc/fstab using vfat if you've got windows or hfs if you've got a mac. You should now be able to access the iPod as a removable SCSI drive! modprobe -r sbp2 to safely remove the ipod (you have to unmount it first, too).
Now, for the GUI. Download ephpod.
Install it using wine (wine ephpod.exe). Change your wine config (probably ~/.wine/config) to use wherever you mounted your ipod as a drive. Startup ephpod. Be sure you've added some nice fonts to your wine install.
Let's not forget that EPIC was originally an HP design. In the late 80's HP had some projects that were using custom parallel processors for a new line of plotters. This idea carried over into it's CPU research under the name "PA-WideWord". Eventually the technology was shared with Intel for the joint venture IA64 project. If Intel's lawyers would look down that road they would be able to claim prior art for Intel and make the patent a moot point.
The idea for EPIC came from HP, long before said Intergraph patent. HP then entered a joint venture with Intel and shared the technology. I think HP can claim prior art here and make this patent issue a moot point. They had developed specialized parallel processors years ago for plotting devices, and this in turn lead to PA-WideWord, renamed IA64 by the marketroids.
IEEEEEEEEEEEEEE!!!!! I'm sick and tired of pulling my hair out while reading about this garbage. Legally, there may be no way to stop these faceless corporations from enforcing Digital Rights reMoved. Let's take down the MPAA/RIAA et al 1776 style!!
Computer Architecture: A Quantitive Approach. THE book for computer architecture, the latest version even includes Itanium (too bad he didn't wait to give his review of the arch til McKinley came out).
Slashdot Mirror
I mentioned in this in a prevous post last summer (/. isn't working correctly now and I can't pull up the link, so if you can browse my user posts, it's in there somewhere)
:D), so far I send enter/leave notify, button press/release, motion notify... windows default to a button grabbing mode and can pass grabs onto other windows, implimenting a popup menu system in a tk should be trivial.
So far I've got the compositing of windows down, windows are displayed hierarchicly and can be composited with any of the gl blend functions, and any arbitrary gl rotation matrix (my switch desktops routeinis going to look somewhat like you're entering hyperspace in the Falcon, cheesey and unnecessary, yes, but definately has a high WOW factor.
The communciation is over pipes and it is very fast, no problems there.
The selection mechanism works great, I just render the window ids to the backbuffer and use glReadPixels to get the id and send window events to the clients. The events I send are just like xlib (no Expose events, though!!
Currently I'm just about to impliment the font selection/drawing scheme (arbitrarily scaled/rotated fonts, resolution independence so you can have nice sized, crispy fonts, and possibly use hw routines to aid in anti-aliasing).
So that's where the project stands. The programming model is similar to X w/o a lot of the cruft. Did I mention it's really fast? Hopefully I'll have a demo out on sourceforge soon, this is NOT vapor...
Cheers, Mike
Has anyone been able to get the ATI fglrx drivers to build with a 2.6-test kernel? That's the only thing stopping me from using it, I've been drooling over the CPU throttling and other ACPI features for some time now, but I can't do w/o my crazy-fast OpenGL either!
Torn,
Mike
Screen quality is measured by contrast, brightness, pixel responsiveness and quality of the glass
;) Still waiting on damned centrino wifi, though. The pentium-M core is pretty sweet, too. Long battery life, doesn't get hot in my lap, and has plenty of processing power when called upon, helped out by the 1MB on-die L2.
The HP/Compaq WUXGA's brightness is one of it's best qualities, along with another trait that you didn't mention for LCDs -- wide angle viewing. The X1000s at CompUSA & Best Buy have the lower end displays, you have to custom order to get a WUXGA model (but I believe they do carry the 1680x1xxx). Anyways, this display is far superior to the apple 15.2. The first comment I get about it is usually "that is the clearest picture I've ever seen". Watching anomorphic dvds on it is amazing!
Oh, and I've made it a Lintel laptop, not Wintel
Cheers,
Mike
Oh, and another thing, the screen is excellent. Probably the best laptop screen I've seen
I guess you haven't seen the WUXGA screens now shipping on HP/Compaq nx7000/x1000 or Dell's widescreen laptops. 1920x1200 resolution, 15.2 diagonal. I can't believe that Apple hasn't shipped a better screen than 1280x854 on it's 15 inch model. My 15.2inch HP has more pixels than the 17inch Powerbook! The picture is amazing. As a side note, the company that makes the Powerbooks for Apple (Compal), is the same one that makes those HP/Compaq notebooks, so I was half expecting 1920x1200 on the new Powerbook, what a let down...
First, what a great idea. Congrats to these guys, as long as they aren't compromising anyone's privacy...
The only songs I download are singles I hear off the radio and want to listen to a little more before purchase. The RIAA could profit off of this if they wouldn't make a cd single cost $8.99 (what bull!). Just sell them in cheap paper/plastic cases (like most pee-cee games, once you get them out of the enormous box, hehe, enormous box...) If only SOMEONE would come up with a way to profit off of cheap, highly available music singles *sigh*
I don't know exactly what the law is about this, but I've never got phone spam on my cell. Lately it's cheaper than the local telco and I get long distance, and the obvious handiness of being mobile. Plus now friends & fam only have to remember one number for me. If I ever do get an unsolicited call, my planned response is "f**k you, this is a cell phone, *snap*". Can anyone enlighten me as to the laws on unsolicited calls to cell numbers? Are they just filtered by service providers?
Cheers,
Mike
I got my start by doing a GUI tk & wm for X, got sick of X, and just started this OpenGL thing a couple months ago. I had the idea for an OpenGL display server a few years back when I was at SGI, and now I'm finally doing it ;) email me mike-d@mike-d.org if you're interested.
Cheers,
Mike
My implementation doesn't use pbuffers/GLXPixmaps, etc. I'm using textures. The "MakeCurrent" functions are very costly in terms of speed, as is swapbuffers.
;)
So, how am I using them? Every window has a front/back texture. The front texture always contains the most current composited version of the window, the back texture is used for drawing operations. When a texture is not resident, these live in unsigned char buffers in main mem ( haven't gotten to the whole memory management stage yet ). Anyways, since the front buffer always contains the current fully composited window, to recomposite the toplevel you only do one textured poly per application.
Now, for fast client side drawing... all off-screen drawing takes place in the toplevel back buffer, which is only swapped when a client wants to update the contents of it's window. Drawing ops first draw with a poly the size of the window with a (GLZERO, GLZERO) blend func, to do a clear (we want to avoid glClear as it is costly). We then draw the current back texture, then do our drawing op. If the server's next drawing op is to the same window, we don't do the clear poly. When another app needs to draw, we read out with CopyTexSubimage. When a client calls "UpdateWindow", the front/back buffers are swapped, and the window is recomposited up the hierarchy, the last step being to draw toplevel windows. This is all very fast, and even older gfx cards (my old quadro) can push enough pixels to have clients draw at nearly 50fps 1024x768.
By way of comparison, using pbuffers/GLXPixmaps and glDraw/ReadPixels and swapping contexts/using MakeCurrent I could only get 4fps (compare that to the Quartz Extreme numbers). I'd love to find people to work on this with me. So far all I've done is test frame rates with the various methods I mentioned, and did a basic client/server framework. Once that's all in place, my toolkit should work well with the new system, and hopefully Qt/gtk
I need to try out your Embedded Mesa driver. That's exactly what I want, a driver that is purely GL. Email me at mike-d@mike-d.org.
Cheers,
Mike
I've always thought that it would be a good idea to reengineer the whole system from scratch to take advantage of today's hardware and UI concepts.
:) All of the drawing is also hardware accelerated. I've figured out a way to do this very well, without context switching the gfx hardware. One possible method will allow many clients to draw at once and keep a constant framerate (by not context switching/swapping buffers within a certain timeslice, these are very costly operations).
Good idea, I've thought the same thing. I wrote a GUI toolkit for X, and a window manager, so I've got a good idea of how the whole thing works. I quit working on it as I was frustrated that I couldn't do some of the neat things I see in OS-X on X (that sounds funny, doesn't it?). Soooo...
I started from scratch writing an OpenGL based display server. I'm using a lot of ideas from X, but throwing out a lot of cruft and adding lots of enhancements. All of the drawing is double-buffered -- no more Expose events!!!!
Some of the ideas I am keeping are the idea of "internalizing" graphics buffers to the server where they can be shared among other applications. I'm also keeping the idea of a replacable window-manager like shell.
For fonts I'm using Freetype. Standard image format is png. The display is also hardware-resolution independent and colordepth independent. Right now I'm being setback by the fact that I can't get X working on my new laptop (anyone know a modeline for WUXGA+ 1920x1200@60Hz, for Compaq X1000?). For communication I'm using named pipes/shared mem.
So far, my numbers are better than these.
I'd also like to implement creating server-side macros so a client can pass one command to the server and execute a whole set of drawing routines atomically. Oh, and the source is definately going to be open. Any of this sound like a good/bad idea?
Cheers,
Mike
I agree, my 15" compaq is 1920x1200 :)
check out the hp-compaq x1000 (www.hpshopping.com) series, they're pretty sweet and dirt cheap. configurable from $1299 w/rebate, up to 1900x12000 WUXGA+, radeon 9200 64MB DDR, 80GB drive, pentium-m 1.6GHz (this processor is sweet, first mobile processor with 1MB _on-die_ L2, to keep it fed with data while maintaining low power usage). I tricked mine out with all this stuff for about $1800. Oh, and a slick mostly-aluminum case. Yes, I know it's a rip off of apple, but it costs some much less for more powerful hardware ( the pentium-m @1.6GHz is comparable to p-4 @2.4, but has around 5hr battery time).
-Mike
Kmart sucks!
What the author is looking for is described in Neal Stephenson's "The Diamond Age". Basically, all your electronic devices are ready and willing to receive and send packets from/to anyone else's devices (in Stephenson's book the devices are nanotech MEMs of some sort). Your encrypted communications just hop along from one person to the next until they reach their destination. I think it's a wonderful idea. Equip everything from phones to handhelds to t-shirts,etc with the ability to route data. The only tricky part is finding where the source/dest are physically located and then routing. You'd need some sort of positioning system that would be a one time cost+maintainence.
Mike
I know I'm not alone with this problem. The flash plugin (or mozilla) does a blocking wait whenever it loads a page that requests sound, so it freezes when I've got an mp3 playing. It's no fun having to stop your music every time some page decides to load flash content. I loathe flash, but unfortunately I sometimes need to view a page that has flash content. Is this a bug in mozilla or flash?
Cheers
Mike
There comes a time when you have to chuck backwards compatibility in the name of progress. The problem is we've got all this existing software that's been tailored for x86. Right now we're experiencing similar problems in the automotive industry, which is much more stodgy than the semiconductor biz. We're stuck with ancient internal combustion behemoths because of people's unwillingness to accept change. Likewise, we're stuck with cpu tech that's relatively much older than our crappy auto tech given the pace of the semiconductor industry.
Let x86 go! Live in the now! Itanium is a great CPU. Sure, the first iteration sucked, but look at it in the same light that you view electric automotive designs. Now take a step back and look at Itanium II. Itanium II is currently the leading performance CPU for floating point code by a small margin over Power 4 ( which, I might add, costs 2-4x more than an Itanium system ). In four months time Intel is said to be releasing a frequency bump to Itanium II with even more L2 cache. IA-64 performance scales almost linearly with frequency! (and no, you don't even have to recompile to reap the benefits of increased frequency) When Dell saw that the Itanium II performance rumours were true, they did a 180 and are now playing catchup to other vendors. IBM has hedged their bets by building Itanium II systems, Sun is dying, and Opteron will be DOA.
Those steps are for someone who doesn't have at least kernel v2.4.20 and the proper modules compiled. Most current distros have all the necessary stuff so you just need to plug it in and mount it. At that point, it's just like any other drive and (like on windows) it's a matter of writing the itunes.db on the ipod. Ephpod is pretty good for this, but it's windows software so requires wine. This is not a permanent solution. Someone will build a nice linux native UI, I'm working on one myself.
my mom had the hardest time installing the software and pluging the darn thing in
I bet she did. For instance, when I plug mine in under winxp as soon as "Musicmatch Jukebox" recognized the iPod the #@!ing computer restarts. I'm not re-installing the (P)OS for this when a kernel compile takes 5 min. I was, however, able to get it to work in windows with ephpod, but all my music is on the linux box anyways and transferrring over the network is slower than firewire. Kudos to the ephpod developers, very nice. Open source it!
Mike
Apparently the site is already /.'ed. Here's a way to get it working with a nice GUI.
;). Be sure to have SCSI compiled in or as a module!! Also be sure to inlude the HFS (if you've got the mac version) or msdos/vfat (for windows ipod) if you don't want to reformat your ipod. Reboot with you new kernel.
/var/log/messages and plug in your ipod and wait for the magic :) You should see Apple iPod being added as a (5/10/20)GB SCSI disk. Add a mount point for the drive in /etc/fstab using vfat if you've got windows or hfs if you've got a mac. You should now be able to access the iPod as a removable SCSI drive! modprobe -r sbp2 to safely remove the ipod (you have to unmount it first, too).
I'm using the latest stable kernel (2.4.20). 1394/ohci/sbp2 are all working great. Be sure to check "prompt for development drivers", then add the 1394 module and be sure to add OHCI and sbp2 (these also help if you're into dv
modprobe the 1394 and ohci modules. Do a tail -f on
Now, for the GUI. Download ephpod. Install it using wine (wine ephpod.exe). Change your wine config (probably ~/.wine/config) to use wherever you mounted your ipod as a drive. Startup ephpod. Be sure you've added some nice fonts to your wine install.
Enjoy!
Let's not forget that EPIC was originally an HP design. In the late 80's HP had some projects that were using custom parallel processors for a new line of plotters. This idea carried over into it's CPU research under the name "PA-WideWord". Eventually the technology was shared with Intel for the joint venture IA64 project. If Intel's lawyers would look down that road they would be able to claim prior art for Intel and make the patent a moot point.
The idea for EPIC came from HP, long before said Intergraph patent. HP then entered a joint venture with Intel and shared the technology. I think HP can claim prior art here and make this patent issue a moot point. They had developed specialized parallel processors years ago for plotting devices, and this in turn lead to PA-WideWord, renamed IA64 by the marketroids.
/me has a similar problem
DeNiro as Lawrence Pritchard Waterhouse ;)
congested hops
... argle,argle
congest-ed hopppppppssss
IEEEEEEEEEEEEEE!!!!! I'm sick and tired of pulling my hair out while reading about this garbage. Legally, there may be no way to stop these faceless corporations from enforcing Digital Rights reMoved. Let's take down the MPAA/RIAA et al 1776 style!!
Sorry, I had to vent... this is so frustrating...
Mike
This isn't a Wizard, it's Willard! hehehe
Mike
Computer Architecture: A Quantitive Approach. THE book for computer architecture, the latest version even includes Itanium (too bad he didn't wait to give his review of the arch til McKinley came out).