login
Search
Please take the following message as constructive criticism, and try to make your replies the same. I am very concerned. I think that the Open Graphics Project is on the road to nowhere. As it currently stands, it is doomed. It is doomed to irrelevance. It is doomed to produce something state-of-the-last-century. It is doomed to produce something that so few people will care about that it will pass away unnoticed. OGP has to fill a need, and it has to fill that need with something that can fit in a reasonable cost FPGA. And the need has to be worth the cost of a low volume design. Any hopes for a final ASIC based on the design are just that: hopes. If every step of the way along the path doesn't provide real benefit for someone, the project will fail. That is the way of open source projects. Whatever OGP does, it is unlikely to have volume on its side. Any design or idea that does not take that into account is doomed. We can't compete with commodity items, and we can't compete with non-commodity items that use many more gates than we have available. Even if a design made it to ASIC, it would be three process generations behind the state of the art, and implemented with far fewer gates than any potential competitor. Its OpenGL performance would most likely suck, and that will always matter at some level. It's cost/performance ratio will really suck, and that really matters. I think there is space for an open source hardware graphics card or chipset. I also think that trying to do an OpenGL implementation in the card is a terrible idea. At every level, doing anything that is anything like what is out there today is a terrible idea. We can't compete with high volume chipsets, even if our drivers and specs are fully open. We can only compete by providing something that isn't out there. It has to be _different_. Even better if it is different and simple. Complexity is a cost, not a feature. If I want an OpenGL card, I will buy a nVidia or ATI card that is reasonably well ...
I look forward to reading it. ===================== Start with actual requirements. I see three basic categories of things a graphics/video chip might do: 1) "desktop" apps X window manager xterm web browsers image viewers (xv, gs/gv/xpdf, ...) xfig, CAD gimp 2) video 1080p sync with audio hardware assist for mpeg2ts 3) gaming more is never enough Last I heard, OGP wasn't planning to attempt the gaming market, at least not for the first generation. Not practical to try to compete with ATI/Nvidia the first time out. I agree. I don't see anything in desktop or video that needs 3D. OGP has been planning on supplying "some" 3D capability, and from what I've been reading, even this limited 3D is going to take forever to design. What if we scrap 3D completely for the first generation and concentrate on desktop and video? Potential areas for advantage: open source (duh) good for high resolution displays (e.g. dual-link DVI) high color depth, accurate colors, calibration low power ( ->low heat ->no fan ->quiet & reliable) good video (Nvidea is weak here) connect via Ethernet, Firewire/1394, or USB instead of a slot Ethernet-to-video bridge useful for home theater, put noisy computer in another room. Same for audio (recording or playback). Also useful for office. allows multiple displays without needing multiple slots independent of slot type (PCI vs PCIe vs ...) support for any display type (CRT, LCD, ...) any sync type (ATI does not support sync-on-green), the mythical 50 Ohm display, etc. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
While our 3D engine will be fast enough to run many games, it is most useful to us for doing things like compositing (alpha blending, transparency), rotation, scaling, and other operations that is interesting for so-called 3D desktops like you see with MacOSX. I've been developing X11 drivers (DDX layers) for various graphics cards since 1996. I have developed drivers for chips from 6 major GPU manufacturers. I am very familiar with X11 and I know what is necessary to develop an efficient driver for everything from UNIX desktops to Air Traffic Control systems. Just off the top of my head, OGA is spec'd to accelerate most X11 2D functions, including: - Lines (solid and dashed) - Rectangle fills (solid, tiled, and stippled) - Bitblts - Copyplane - Polygons (indirectly as triangles or spans) - Text - Image upload/download - Raster operations and planemasks You don't optimize for applications. You optimize for the rendering functions that these applications require, which is dictated in large The video stuff is in there. And at the very least, we'll support Except all that nifty scaling, rotation, and compositing stuff that Well, yes, the timescale has been a bit of a problem. We'll see if Then we won't end up scrapping 3D. I feel like I'm repeating myself. :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Perhaps I need to go find a store that sells Apple and look at this wonderful and glorious "3D desktop", but somehow I suspect I can live without it. Given that I don't recall anything memorable from a I don't buy a computer to do "rendering functions". I buy one to run a web browser or be a DVR or a firewall or whatever. So the process *starts* with the apps. And thus far, "3D desktop" is not on my list. Once you have the list of apps/functionality you need, then you figure out what it takes to do that. The next level would include things like, a display with 1280x1024 or 1920x1080 or whatever pixels and 24 bit or Video needs scaling. (Scaling is 3D????) What needs rotation, and compositing stuff? What needs programmable shaders? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I want 3D on Linux to run: Blender Low-poly games like Penguinplanet Racer, etc. 3D CAD apps that haven't yet been written These things *crawl* on a framebuffer card (or don't function at all), but they aren't really all that demanding on reasonable 3D hardware. They work fine on the ATI 9200, for example. But here's my question -- what happens when the ATI 9200 disappears from the market? The later ATI and nVidia cards are all closed designs. I would like to see a card that is actually working with free software driver developers and not against them. That's what makes me interested in seeing OGP succeed. Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I feel the same way. I'm currently of the opinion that perspective correction is about the only think that would get removed from OGA (in the abstract) to make it satisfy Ray. But if that doesn't require too much hardware, why not keep it? Actually, a 2D design is WAY easier to parallelize than a 3D design. That's because 2D designs are much more rectilinear, so you keep parallel fragments together, reducing the amount of metadata that has to travel through the pipeline. For instance, all but the last few stages of TROZ's pipeline is all metadata. Just coordinates and a little bit of other information. On the other hand, OGA carries color information essentially the whole way through the pipeline from beginning to end. Still, what Ray is asking for would be more like OGA than TROZ. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
T24gNS8xMi8wNiwgUmF5IEhlYXNtYW4gPGxpc3RzQG15dGhyYWwub3JnPiB3cm90ZToKPiBQbGVh c2UgdGFrZSB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgYXMgY29uc3RydWN0aXZlIGNyaXRpY2lzbSwg YW5kIHRyeSB0bwo+IG1ha2UgeW91ciByZXBsaWVzIHRoZSBzYW1lLgo+Cj4gSSBhbSB2ZXJ5IGNv bmNlcm5lZC4gSSB0aGluayB0aGF0IHRoZSBPcGVuIEdyYXBoaWNzIFByb2plY3QgaXMgb24gdGhl Cj4gcm9hZCB0byBub3doZXJlLiBBcyBpdCBjdXJyZW50bHkgc3RhbmRzLCBpdCBpcyBkb29tZWQu IEl0IGlzIGRvb21lZCB0bwo+IGlycmVsZXZhbmNlLiBJdCBpcyBkb29tZWQgdG8gcHJvZHVjZSBz b21ldGhpbmcKPiBzdGF0ZS1vZi10aGUtbGFzdC1jZW50dXJ5LiBJdCBpcyBkb29tZWQgdG8gcHJv ZHVjZSBzb21ldGhpbmcgdGhhdCBzbyBmZXcKPiBwZW9wbGUgd2lsbCBjYXJlIGFib3V0IHRoYXQg aXQgd2lsbCBwYXNzIGF3YXkgdW5ub3RpY2VkLgpbc25pcF0KPiBGdXJ0aGVybW9yZSwgYXMgcHJv Y2VzcyBmZWF0dXJlIHNpemVzIGdldCBzbWFsbGVyLCBpdCBiZWNvbWVzIGhhcmRlciBhbmQKPiBo YXJkZXIgdG8gZGVzaWduIGZvciB0aGVtLiBGUEdBcyBkb24ndCBzdWZmZXIgZnJvbSB0aGF0IHBy b2JsZW0sIGJlY2F1c2UKPiB0aGUgdGlueSBmZWF0dXJlIHNpemVzIG9ubHkgaW1wYWN0IHRoZSBp bml0aWFsIGRlc2lnbiBvZiBhbiBGUEdBIGNlbGwsCj4gYW5kIGV2ZXJ5IGRlc2lnbiB1c2VzIG1h bnkgcmVwZWF0cyBvZiB0aGUgc2FtZSBjZWxsLiBGUEdBcyBhcmUgZ2V0dGluZwo+IGNoZWFwZXIg YW5kIG1vcmUgcG93ZXJmdWwuIFBlcmhhcHMgd2Ugc2hvdWxkIGp1c3QgY291bnQgb24gdGhhdCBh bmQgdXNlCj4gaXQgdG8gZG8gdGhpbmdzIGEgc3RhdGljIEFTSUMgc2ltcGx5IGNhbid0IGRvPyBJ IGNhbiBzZWUgdGhlIHBvaW50IG9mCj4gZnJlZXppbmcgYSBzdWJzZXQgYW5kIGltcGxlbWVudGlu ZyBpdCBhcyBhbiBBU0lDLCBiZWNhdXNlIGl0IHdvdWxkIG1ha2UKPiBtb25leSwgYnV0IGlmIHRo ZSBGUEdBIHZlcnNpb24gb2YgT0dQIGRvZXNuJ3QgaGF2ZSBhIHJlYWwgdmFsdWUKPiBwcm9wb3Np dGlvbiBmb3IgcGVvcGxlLCBpdCBtYXkgYXMgd2VsbCBub3QgZXhpc3QuCgpLZWVwIGluIG1pbmQg dGhhdCB0aGUgZmlyc3QgJ2J1eWFibGUnIGNhcmRzIGFyZSBzdXBwb3NlZCB0byBiZSBvbmx5IGEK J2ZhbmN5JyBGUEdBIHdpdGggbG90cyBvZiBtZW1vcnkgaW4gd2ljaCBkZXZlbG9wbWVudCBvZiB0 aGUgZ3JhcGhpY3MKY2FyZChhbmQgc291bmQsIGFuZCBzZWNvbmQgZ2VuZXJhdGlvbiBwcm9ncmFt bWFibGUgZ3B1KSB3aWxsIGhhcHBlbi4KSXQncyBhaW1lZCB0byBiZSBzb2xkIHRvIGRldmVsb3Bl cnMgYW5kIHVuaXZlcnNpdGllcywgbm90IHRvCmVuZC11c2Vycy4KSWYgeW91IGFyZSBldmVuIHRo aW5raW5nIHRoYXQgc2VsbGluZyBhIEZQR0EgZ3JhcGhpY3MgY2FyZCB0bwplbmQtdXNlcnMgd2ls bCBiZSBwcm9maXRh ...
There is some risk that our fixed-function shader is so out of date that it won't meet the needs of many users, but your suggestion of This is why I have spent so much time trying to set up business relationships so that we can afford to produce this ASIC. Some of the answers to what we'll do in the future, however, dependent on what happens with OGD1. One of its purposes is to attract business partners. Once they know we're serious and capable of building real hardware, we hope we'll attract attention from companies with money This is precisely why the stated primary target market for OGA is embedded systems, not open source. Our analysis suggests that OGA will compete extremely well on both price and performance in that market. Power consumption is an issue we're going to have some trouble predicting, but many embedded systems are not so Actually, its performance will be right around what you'd get from any fixed-function engine that can move 6.4 gigabytes/sec through its The 2D vs. 3D argument has been beaten to death. You may want to sift through the archives (and LKML posts on this topic) where the number of people in favor of a 2D-only design were a tiny minority. The decision was made to design a pipeline compliant with OpenGL 1.3 (and some later features) and tweak it so that it would perform well on 2D tasks as well. In fact, the stated primary intended uses of this design are "2D desktops plus the simple 3D eye candy that is popular in recent UIs." The fact that the design is based on a 3D pipeline doesn't mean that we weren't attentive to the needs of 2D desktops. Sure, having floating point and textures and such in there complicates things, but the tradeoff is worth it to maximize the market as much as we can. What do you think will get bought more? A 2D only engine? Or a 3D engine that's also good at 2D? The only thing that 2D-only would give us for the same amount of logic is wider issue, which helps in some cases and not in others. ...
Probably the most useful response I can give immediately is to say: When I say OpenGL or 3D, I think they are both a bad idea. We don't need 3D, and when talking about 3D, we don't need to be contaminated with the idea of adding OpenGL-like features. It's a bad idea layered on a bad idea. They are bad influences, both, because they jump to solutions before problems are considered fully. Porter-Duff compositing implies sub-pixel alpha blending and does not imply 3D. For a long time I read everything that went by on this list, and my impression is that you came out of the gates with the idea of doing 3D, and that part was never really discussed in a meaningful way. The alternative was too simple and badly defined to be meaningful. I eventually stopped reading everything a month or two ago when I lost hope in OGP's future. The fact that you say everything I say implies "3D pipeline" to you illustrates my point exactly to me. You are stuck in an box of preconceptions. You have never been out of this box, and your proposed solution is overcomplicated as a result. My requirements imply several things to me: 1) Polygons 2) Layers 3) 2D 4) Compositing 5) An efficient representation for data that takes advantage of the above, and allows efficient encoding of scale, rotation, translation and depth for objects and their children. There is a useful concept that I think needs to be kept in mind in graphics: The fastest way to do something is to not do it. This is a comment on the general way in which people should implement graphics primitives nowadays. Why copy something when you can just read the data from the new address? Similarly, we need things to layer over other things, but we don't need perspective correction. The Z axis implies visibility only, not scale, and we can encode that information without requiring Z values on each input polygon. Similarly, we don't need texture mapping. Sure, we need some way to represent rectangles of pixels, but use the word ...
I see your point. But keep in mind that yours is only one opinion. It might be the only right one, but you're coming here a significant length of time after "3D" was a foregone conclusion. Thus, you have a There are a lot of things that can be implied by this. Are you saying that there is more than one alpha value per pixel? Are you saying that there is more than one pixel in the framebuffer per pixel on the That's not accurate. I came out of the gates suggesting a fast 2D You know, sowing the seeds of doubt is hardly a good way to help a project like this succeed. If you think there's a problem, help fix My reasoning here is that everything you described is something that is supportable by the "3D pipeline" that we had defined. I make no claim that this design is an optimal one! One of your obstacles is that you've not yet given a frame of reference for this new and improved idea you say you have. What you might want to do is have a look at the OGA model and point out specific examples from its design that are unadaptable to a better design. I have a feeling that a better design would have at least a superficial resemblance to the design we've already spec'd. Therefore, it makes a good frame of reference for describing a new design. Also, you've made statements that you believe that 3D isn't appropriate. Ok, fine. If you're right, then it shouldn't be too hard to convince me with solid logical argument. I have a history of changing my mind in the face of arguments that run counter to my preconceived notions. Tell me why it's not useful to support an OpenGL-like 3D rendering pipeline. Describe to me your alternative and explain how it meets our needs better. Tell me how I'm going to sell this new design to a buzzword-driven market that expects everything to be 3D whether they use it or not (something I've seen in ATC requirements specs more than a few Fair enough. So if we can add perspective correction cheaply enough, Well, I kinda ...
My guess is that the 2D support for OG's engine will be ready long before the OpenGL drivers are, so Ray might get what he wants by not upgrading to then newer drivers with 3D... ;-) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I will reply with more in this particular thread later, but I want to make it clear that I am not saying I have a better idea. I'm saying I have serious doubts about the way things are going. I'm saying "The Emperor has no clothes", not "I have the Emperor's clothes". I'm not trying to just dump on the whole project, but I am extremely dubious about the direction things are going in and I am trying to explain why there is a problem. I am trying to air dirty laundry and make everyone re-evaluate where we are. One of my points is that I think the current target is simultaneously too similar to the other stuff out there and too complicated to be a good first project. Complexity is a cost, not a feature. I do have an idea. It's weird and purposely "out there". I'm not going to bring it up now, because I'm not claiming that it's the answer to OGP's problems. I don't want a discussion of my idea right now, but a discussion of where OGP is today. I WILL put forward my idea later, but please bear in mind that I am not claiming it as a solution. It's just "different", and I hope that it might interest people more than a copy of everything else out there. I only started bringing it up, because I had to reply to your comments about 3D pipelines. I'll be replying to the other emails in this thread shortly. Cheers, Ray _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
You should feel lucky I'm not Linus. :) Geek psychology doesn't take well to people who complain a lot but don't contribute something better. You either need to provide solid arguments or an alternative design that is demonstrably superior. You obviously have something in mind, so spill it. Also, if you go too long without contributing viable alternatives, people are going to start assuming that you're a shill from one of the other graphics vendors who feels threatened and wants to poison us Surely, we do not want to delude ourselves into thinking that everything about what we're doing is optimal. But I don't think any of us feels like we have a solid handle on the future of things here. If OGD1 were the only thing we ever produced, we'd still be going a long way towards making it easier for hobbyists and FOSS enthusiasts You're dubious because you feel that we're getting caught up in a narrowly thought out plan and we're going in the wrong direction. You think we're being brainwashed by "OpenGL" and "3D". Ok, I get it. We've been working on a "3D" design, while what you're asking for is something like a "2 1/2 D" design. Whatever. Who gives a crap what you call it. The things you've asked for, as far as I understand them, are either special cases of things provided in so-called "3D engines" or a minor generalization of such things. I'm not the world's top hardware designer, but I do have SOME sense of how much logic one thing or another is going to require. You haven't convinced me that we should do any thing more than look over our existing design and make sure it's general enough to do all of the things you think it should do while at the same time considering what features could be removed because they're not helpful. Don't get distracted by the fact that we call something a "shader" when it's just a generalized source image fetcher. Exactly HOW we design it is arbitrary. Any number of different approaches can be taken with similar performance and ...
Hi Ray, I would like to say that I completely agree with your view that 'The Emperor Has No Clothes'. About a year ago, if I got that right, I was very excited about the project and wanted to help actively. So I put forward that we needed a 'vision', a.k.a. 'elevator pitch', a concise description of the problem, the solution, and the strategies to make it a reality. This created a slightly heated discussion, ranging from "we already know exactly what we want and how we're going to do it", to "I need features XYZ as well" and "only solution ABC will work". So clearly nobody really knew what the project was about and it had already attracted a lot of people with big wishes and the wrong ideas. A vision statement appeared on the Wiki but it's more like a solution in search of a problem. Frankly, the situation hasn't improved much. In fact, one of the fundamental questions raised a year ago still exists: Do we really need open-source hardware to solve the actual problem? As you have indicated as well, it is very much a software problem. Hardware can solve ONLY the performance aspect of the problem but that's just a fraction of the work (not underestimating the complexity of hardware design). What we need (first) is a complete software infrastructure, from high level GUI API to 2D/3D API, to O.S. interface, to kernel, to driver, to device emulator. I'm a software rendering nut, with experience in embedded devices, and I'm convinced that a good emulator and all the layer of software on top of it would already make a huge difference with today's situation, completely solving the problem of not having open-source drivers. The only issue remaining is performance. But CPU's are getting faster by the day and GUI work isn't that computationally expensive anyway, so emulation is acceptable and it's the fastest way to get the application programmers started. The hardware can follow later, which will be much easier to design because at that point we know exactly what it needs to be ...
Actually, what you're suggesting is an excellent idea. I developed a software model of OGA. How about we take it from another direction. We don't know exactly what needs to go into the design, but we can figure it out empirically. Start by making up a set of rendering features (forget "2D" and "3D" and start with "stuff we need"). Develop a DDX, a kernel driver, and some user-space pseudo-device that everything talks to and which pretends to be this piece of hardware. It can talk to any existing graphics card whose framebuffer we can init and mmap. Instrument the heck out of it and profile it. From this, we'll figure out which features are most performance critical and which are not. We can consider tradeoffs between software rendering (in the DDX) and hardware rendering (in the simulation of the hardware) and estimate relative performance, etc. As we're going along, we need to still think like hardware designers. Break things down to "primitives" and "attributes". Primitives correspond to high-level operations, and attributes correspond to variables like colors and coordinates. When OGD1 is ready (which it probably will be before the above is finished), we implement a bunch of this in hardware and try it out. If we discover that we have room left over, we can revisit some of the ideas we threw out and see if it won't hurt to include them for "future proofing". Note that we figured out a lot of the math when working OGA, so borrow liberally from the model rather than reinventing the wheel. Same goes for software rendering parts of X11 (cfb/fb/mfb/mi). Get in tough with Keith Packard and tell him that we're reevaluating our direction and that he can get essentially any sort of feature he and his colleagues with X.org could want. What do they need? What do they want? Since the focus right now is getting OGD1 finished, it would certainly not be an unwise use of time to reinvent OGA while it isn't in the critical path. Just keep in mind that it needs to ...
What we have today is a documentation problem. We probably don't need to know the gory details of every single transistor in a graphics/video chip, but we do need to know how to write software for the chip. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
We *NEED* "open hardware": i.e. hardware for which documentation is readily available to make software drivers for it. But I *WANT* that to be "free hardware": i.e. hardware for which the design is published under a free-license. This is future-proofing: if the original manufacturer stops making the card, someone else can fill the need. In practice, this tends not to need to be used because the buyer confidence in a future-proof product is such that it increases the perceived value of the product, making it very successful, so that the company doesn't need to discontinue it (or not until something much better comes along, at least). Also, you have to realize that free hardware is always a matter of *degree*: 1) Do you need to know the entire engineering process behind each capacitor or resistor on your circuitboard? NO: because capacitors and resistors are replaceable commodity components; you only need to know their ratings (3 or 4 numbers); there are loads of suppliers; and there is no danger of them becoming unavailable. 2) Do you need to know the design of chips? Well, maybe. It depends on how commoditized they are. 74xNN chips are ubiquitous; there are free-licensed designs for them; and loads of substitutable components -- so who cares? Use whichever brand is cheaper. But a proprietary ASIC or CPU is something that can render a free-licensed adapter design useless if that chip should be withdrawn from the market. So ... 'free hardware' is a selling point. But I also acknowledge that a company needs to protect it's proprietary edge if it is investing in card or chip production. There are a number of well-defined strategies for implementing that balance though: license-delay schemes, proprietary enhancements (but with a solid free-licensed reference design), etc. Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing ...
You have to remember that the first pc was totally open. And a lot of people earned a big pile of money. -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yep. WIth published sources etc. I think I still have a copy of the tech ref for the IBM PC. I learnt a lot from that code. Including the ability to see WHY things failed when they did & why not to pass certain values to bios routines. H _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
And also remember that the Apple ][ was open and sold well. The Mac was closed, and sales fell off. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
You'd be surprised. About 10 years ago Allen-Bradley quit making carbon composition resistors, because sales were petering out in the face of surface mount assembly, and the production machinery was completely worn out. The Defense Department went nuts and tried to put a stop to the shutdown, even offering to buy the machinery, because carbon comp resistors have the unique property of being able to handle heavy short-term surges without a lot of parasitic inductance. That's key to building electronic subassemblies that can handle ESD, lightning surges, and EMP. No luck, Allen-Bradley dropped the line anyway. Eventually a couple of companies in the far east started making carbon comps, but they're not nearly as well Not necessarily. Some competing 74HC designs with the same part number have different internal logic designs, which can affect propagation delays, setup times, and the test vectors you need to use if you want to detect hardware failures. That's important in some safety-critical designs, where the regulatory agency requires that a failure result in a safe shutdown within some hard time limit, like 4 seconds. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
At the risk of being shouted down, I say BULL. When was the last time Intel, AMD or IBM, SUN etc released a CPU that had no register level description? Never. That's when. Because people expect to be able to cut code to run on them. For some strange reason the graphics vendors have got into their heads that somehow they're so much more special than the CPU vendors when all they're really doing is producgin a specialised processor that runs through & performs the exact same thing as a general purpose CPU (i.e. follows instructions & peforms some memory alteration because of them). There is no need or defense for vendors to keep their hardware interface secret. At the very most I'd forgive them for doing something like Intel with their wireless (802.11) chipsets like the ip2100 and ipw2200. All they need to do is build a chip with an open & documented interface. Who cares HOW it does it, as long as it does what it says on the tin... Keeping secrets seems like it's more to protect themselves from having their faults known than anything else. (Sorry. Shouldn't post when I've been drinking I know). But this thread is gettign annoying. If you don't like the OGD, build your own competing product & sell that. Heck maybe two new products would be enough to make Nvidea & ATI realise we're not quite a thick & ham fisted as they seem to think & can really be trusted to know & see the code to interface to their chipsets. H _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Hmm. To which bit? The point I was making here is that *open hardware* (well-documented interfaces) is a requirement, but *free hardware* (completely documented implementation) is not. OTOH, free hardware *is* a selling point -- given a choice, and a price which is not extraordinarily high, I'll expect to pay more for that privilege. But I see it primarily as "future-proofing", so if the information is guaranteed in some way to be published in 3 years, that works about as well as immediate publication for me (for me, the issue with delayed publication is not the delay, but the doubt -- will the company follow through on that promise?). I'm not in the business, so I can't honestly judge the viability of publishing your complete implementation right away. If there's a strong reason to keep enough secret to recoup costs (and a reasonable profit) before the Ah. Then you actually agree with what I said. I would classify that as "open", not "free". "Free" hardware means I could (assuming I had a chip fab, surface mount oven, and skills I don't have ;-) ) build the product myself from the available documentation. "Open" means I've got all the information needed to use the Heh. Probably not ... always gets people into trouble. ;-) Well, I can't speak for anybody else, but I'm personally talking about the OGD project. I'm saying that if Traversal Tech needs to delay implementation design publication, I can live with that (but to be honest, I was until quite recently confused about the status of the project and had "Traversal" and "Tech Source" confused). OTOH, since OGD has become a 100% community project, it seems unlikely that such a trade is necessary, so my point is probably moot anyway. Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing ...
Actually, it's a double-edged sword. Without putting GPL on the RTL, I can't get enough community support, but many people who would buy our products would shy away from them on the grounds that someone may legally copy our design and put us out of business. A vendor need staying power, and it's hard for them to have that when they "give away" every detail. Like I have said, I'm doing what people asked me to do. But if that is the cause of Traversal going out of business (as opposed to a myriad of other catastrophes that are more likely), then they'll have proven themselves foolish and shown the GPL to be not the gospel they We did get some valuable help with OGD on the list, but unfortunately, we don't see to have many PCB designers. This is why we haven't published the artwork and won't until we have the time to spare. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
IIRC from previous discussion, the OGD1 design will be fully published right off the bat. It's the TRV10 ASIC that will have some portions of its internal design kept private for some period of time necessary to meet Traversal's essential business needs. And I think everybody eventually came around to the realization that it's the best deal we're gonna get, and we need to charge ahead with that issue settled. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keeping the internal design private for 'a while' is (IMO) fine... As long as the interface is open & well known (And in order to be compat with OGD it has to be) and does what it says, I can't think of any objections off hand... Just like a CPU (probably my favourite analogy)... AMD & VIA create new x86 CPU's without problem (Admittedly Intel would probably rather they didn't), but this is good... Imagine what we'd be stuck with from Intel CPU division if they didn't have competition like that... H -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEcenJ/3QXwQQkZYwRAtItAJ946TLrLHa7GhPRyfLcEKjecjApagCePHXE PPetIX658hZrlDe6XxPsGJk= =EOtj -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Why would the possibility of a copycat product make customers shy away? They would then have a 2nd source. Having a 2nd source used to be considered a good thing, often considered essential. If copying a free/open design is such a slam-dunk business plan, why isn't Microsoft selling MS-Linux or MS-BSD ? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Second sourcing is fine for the customer. But if it puts the designers out of business, you only get one chip. Who's going to design the next one? Take a moment to reflect on the history of the OGP. Between when we started in October of 2004 and now, how much hardware have we sold? How much have we DESIGNED? Now imagine what things would be like if I decided that I had better things to do with my time. The only way we'll ever be able to put out new hardware at any kind of reasonable rate is if I do this as my full-time job. I'm creating a business out of this purely for pragmatic reasons, those being that I would like to actually manufacture some real hardware, and this is the most effective way I can see to do it. If someone makes it impossible for me to conduct business, then I'm out of a job. At the moment, I have the uncertainty and hope for the future pushing me along. I dream about people being able to buy open-architecture graphics hardware so we don't have to put up with proprietary drivers anymore. If I could know for certain that this was never going to work, I wouldn't waste my time. If I produce a product but I can't sell it, then that uncertainty and hope disappear. For Microsoft, that would dilute their business model. The more they support an alternative OS, the less control they have over the world. They would be eliminating the one thing that keeps them a the top: vendor lock-in. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The developers and end-users need the thing to be well documented. The business wants protection from competition using that documentation without paying for its creation. This is exactly the problem what copyright and patent protection were invented to solve. So... maybe what you want here is a conventional copyright, rather than the GPL, the so-called "copyleft". Or perhaps a conventional copyright that automagically converts to GPL after 'x' period of time. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Whenever I suggest this, GPL zealots flame me into submission. If I'm going to market to Free Software users, it appears that I have to appease this very vocal minority. True, most of them don't understand the business issues, but they cause me so much bad PR that it's not worth my time to resist. It's a Borg thing, I guess. The irony is that I'm a GPL zealot and have always intended to release the whole thing under GPL eventually. But that doesn't seem to get through, somehow. :) However, in practice, my plan is exactly how you described it. I will put a conventional copyright on it that converts at a later time to GPL. And if I can get a law firm to hold onto it pro bono and release it for me at a later date, I'd be happy to hand it over to them. I would like to do this as a statement of good faith that I'm not going to go back on my word. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
One point of difference is you have the code as a dual license. Competitors will only have access to GPL code. Because your company has built trust, only you will be able to offer the dual license. jb _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That is absolutely true. Only Traversal has full rights. And there may be a substantive market for the IP for this thing. But that still doesn't stop someone from legally putting me out of business. Trust doesn't always mean much in the face of a 30% difference in retail price. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That brings up an interesting thought... Timothy, have you considered Traversal as an IP-only design house? Something akin to the ARM folks, but with designs released under the GPL. That way, the community could help with design work, others could shoulder the burden of production costs, and Traversal could sell IP-rights to folks who want to make modifications _and_ keep secrets (which could be a substantial market if we're talking integrated graphics - the entire rest of the 'northbridge' at least). Just a thought. --tim _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I have thought that once we have the IP ready, we can license it to chip vendors and work out a financial deal for us to both make money from it. We can then have multiple vendors, etc. The thing is, I think someone mentioned that Bitboys tried this and were rather unsuccessful. I expect that when OGD1 prototypes have photos on the web, we'll see a lot more people taking us seriously. People like to see something tangible. A lump of Verilog code is not very tangible. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Heh... bitboys. Without being associated with them, I think they created their own problems. Each successive round of hype coming out of that company placed their supposed designs at least anohter year or two ahead of anything else on the market. Eventually they were touting designs that would rival today's GPUs if they'd ever existed (I remember talk at least of 16Mb of embedded DRAM). Traversal won't have that problem... OGA will feel... hmmm... slightly dated? Which is fine so long as it satisfies a need. And in Sure... What all did the ARM folks offer (besides the Verilog, HDL, or whatever)? Perhaps the community at large could prepare some of the nescessary materials given the GPL'd Verilog. That would give Traversal an added (possible) revenue stream with minimal extra effort. --tim _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
You have a point. Unrealistic hype doesn't help one's credibility. Of course, it's possible that many think we're already guilty of that I'm willing to work with anyone willing to work with me. :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The proprietary bit... mentioning proprietary means to me there's a hidden undocumented interface to talk to the sucker & the un-blessed Yeah. I see now we're on the same wavelength. As far as what we expect Only for the ASIC IIUC. But that's fine as long as the ASIC just implements an open interface, & does it correctly, who really cares exactly how it does it... (Although I do believe like DRM it's only the end user it affects. If someone wanted to copy it badly enough they'd slice it open & duplicate it. Like the pirates apparently used to do with arcade machines in the 80's & 90's. Having said that if Traversal made an ASIC that implemented the OGD register level interface & kept the internals secret forever, then as long as they hadn't broken copyright by using someone elses code internal to it, who's to complain? Mind you at that level it's no different from Via or Intel chipsets is it? The openness is the differentiation between them & if it's LGPL'ed that has the advantage that a competitor can't just use the code & build their own & sell Sigh... Depending on price & speed (And company funds of course) I'll be happy when the OGD1 gets released... Do we have a date yet? I don't remember seeing a recent timeline. Maybe I just missed it. H -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEceuo/3QXwQQkZYwRAk4qAKCHdSUUEEqsGgl33vmN7nUSvwHuogCfe2+w IP05aRGXGupUtEvZikj1lio= =P5vc -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Then they will be locked into predefined architecture and will take path of Intel or AMD hacking around unforeseen limitations. No way they will do it if they are smart. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not sure what you're getting at... The interface for an x86 CPU is the instruction set. AMD don't seem to have a problem innovating within these parameters. (e..g AMD64 being the arch that has gotten around the 'unforseen' 32bit address limitation). Hamish. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEcv9Y/3QXwQQkZYwRAqGmAJ9iMGCavt/lxKWl4YNvEUKl/Ts0pgCgjvZU sbOPt7RDsWGuLrc+JPoTx4U= =924Q -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
RISC instruction set has no x86-specific problems, like accumulator-based integer arithmetic, stack-based FPU and large decoder. I think that by locking the interface, and very specific interface like instruction set architecture, Intel locked itself (and its followers) into the trap. They now need to spend energy twice - first for innovation and second for soldering innovation and legacy. By changing inteface to better suit the implementation (as RISC designers did) you reduce energy spent to develop something new. By locking inteface you lock out a good part of you total energy. That's why none of the AIT and NVidia will open their intefaces or agree on open one. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That was the 80's. Even now, RISC is somewhat passe in academic circles, because of its own inherent drawbacks. For one thing it has code size issues that people would like to overcome. But the bigger problem is this: When RISC processors were first developed, they tailored the instruction set to the underlying architecture, which made it very efficient. But some of the design decisions that made sense then (like branch delay slots) became a liability later when they decided to extract more performance using superscalar and superpipelining techniques. Today, if you want to design a fast processor that's special purpose, the favored approach seems to be VLIW, although that has problems worse than RISC. But when it comes to general purpose processors, we're seeing that the translation from the ugly x86 ISA is becoming a smaller and smaller part of the logic on the chip. The more compact instruction set requires smaller instruction caches for the same performance, with few of the drawbacks, because the decoder can be smart, combining and splitting x86 instructions as necessary. Back in the 60's and 70's, the approach to designing processors was to develop an instruction set and then design hardware around it. The result is things like the VAX which has completely orthogonal addressing modes, which is a total waste since only 3 or 4 of them actually see much use. In the 80's, there was a "revolution" of thought in that area, where instruction sets were designed around the hardware. Today, with superscalar and other sorts of multi-issue super-pipelined designs, we're starting to return to a more abstract view of instruction sets. In my opinion, the holy grail right now would be an instruction set that is based on profiling of thousands of existing applications, taking the top few percent of instructions and filling in the rest for completeness. (Since the apps would be biased by the architectures they were compiled for, this would have to be an iterative ...
Profiling... that rings a faint bell - szefirov posted some profiling with his 'Partial dataflows for pixel and vertex shaders' post. I think he was doing an analysis of shaders on DirectX SDK.. Is this what you are suggesting for OGP? jb _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well, I was talking about CPU instruction sets in general. But in a future OGA design, we will probably want to have programmable shaders, and we'll be doing this kind of profiling and iterative design. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well, I have been doing embedded development (hardware, firmware, HDL, circuit design and software) in various fields for around eight years now, and this is the way I would see it today: I have to design a device and I need some kind of graphical output. Ok: 1) If I am running am embedded windows application, I can use a proprietary chipset and its drivers. Done. 2) If I am running an x86 CPU, but not any well defined OS, I can use whatever is in the support chipset, in VESA mode. 3) If I am running an embedded x86 CPU, and it has an integrated framebuffer, I use that. 4) If I am running an embedded non-x86 CPU with an integrated framebuffer, I use that. 5) If I am running an embedded non-x86 CPU without integrated framebuffer, I will either: A) change the spec to use one with integrated framebuffer B) switch to an x86 processor C) sign the necessary NDAs with a company to get access to programming information for a proprietary chipset, and program it myself. D) (Not a real option today) use an open chipset that is well supported and program it myself and/or use open source libraries. Given a framebuffer that I have to program for, I will want the framebuffer to be as simple to deal with as possible. i.) If I am doing boring UI stuff with limited input (say for example, a GPS navigation map), I will use the simplest framebuffer mode available for the task, program it and be done. ii.) If I am doing something that requires video, I will use a chip with a framebuffer that accepts YUV directly, and potentially has MDCT acceleration or motion compensation. Once the task reaches a certain level of complexity, it makes sense to use something supported by code that does the job you need. I'd probably use one of the VIA processors with a VIA supporting (CN400, say) chipset and ffmpeg or mplayer running in fbdev mode. ie. No X. So, there is a little wiggle room for an OGP chipset in 5C, because inter-operating with any chipset is hard, and the support from ...
Well, it wouldn't be a big deal to design a chip that was nothing but a video controller, a host interface, and some memory logic. Of course, I'm not sure what would differentiate us from anyone else, but early implementations on OGD1 are going to be just that, just to get Yeah, but those questions don't make sense. It has a "rendering pipeline" that is capable of doing some stuff that people call "2D acceleration" and some other stuff that people call "fixed-function 3D fragment shader". It uses minimal power when it's not rendering anything, but more than if you didn't have it there in the first place. Keep in mind that this is designed for applications that would benefit You don't "turn on DMA." You send it commands that result in DMA. You can access everything without using DMA if you want. It's just Yeah. Just a translation between the host interface and the memory. It doesn't matter what (PIO write or DMA read) that caused the data to The legacy VGA emulation is off by default and only turned on when a There's always going to be a bus. It may not be a standard one like PCI, but there's always some communication path between the CPU and this chip. It's either a bus or point-to-point. But who's going to Are you saying that it should behave like, say, a DDR-SDRAM chip? It Again, you're talking about some sort of custom bus interface. How There's always a communication path between the CPU and the support chip. We usually call such a thing a "bus" (even when it's on a You'll need to clear up some of what you've said, because it doesn't all make sense. But I see your point about having a very simplified interface. These days, though, we don't design systems by taking a 68000 and wiring up RAM to it and and ROM and using 74138's to do address decoding, etc. Most things use some pretty standardized Well, OGA isn't obviously wrong to me (yet). I haven't made any decisions to change it. I just hate being wrong and therefore ...
*sigh* Boy, you really missed the point. Did you do that on purpose? I was trying to show you the way I would think if I was doing a design. The really really _really_ important bit was the bit you didn't reply to. You know, the part that showed that I had no compelling reason to use your chip? The bit about where I imagined an ideal world was written on the fly, and showed what would be closer to what would be useful to someone who really does embedded stuff. It was NOT a suggestion for what we could do. It was an indicator of just how far off the mark the current spec is for really embedded stuff. I am saying over and over again: I CANT SEE ANY REASON ANYONE WOULD BUY YOUR CHIP. I even explained how I would be thinking in that sort of situation. I showed a bunch of different cases and showed how little room there is out there for OGA for embedded designs. Why would I use it when I could just use a VIA processor and a CN700 chipset? I get: A) SHA, DES, AES at 20 Gbps. B) A nice CPU that may or may not require a fan. My choice. C) MPEG2, MPEG4, 2D and 3D acceleration. D) FULL SOURCE CODE for everything. X drivers and 2.6 kernel code. Never mind that most of the time (D) is irrelevant. Why are you making this thing? Who will buy it? You claim it is for embedded use, but I have been doing embedded design for a long time, and I don't see any real reason to use it. Desktop use? I have already explained that it will be more expensive and slower than other things I could buy that will have open source drivers, assuming you can find the money to actually get real silicon. Tell me why I should care this thing exists. :-( Tell me why enough people for it to be worth your while to do this will care? Cheers, Ray _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Really? Im running on uclibc. I have simple graphics on framebuffer. I dont want X. I am trying to write a bios for subsecond bootups into my non WIMP graphic ui which is slow now because there is no available open graphics card i can use any acceleration from. I would love to buy this chip! Now if someone can also develop an alternative pc architecture that costs less and does not need a bios then that would be much better. -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Good. My question is how many gates for that simple implementation? You want to have something real ASAP, cheap. That means 50K, 100K gates tops, and you have something within reach of release in a standard cell I'm trying to tell you my first thoughts when I am doing triage on your datasheet, assuming I know nothing else. What I am saying is "Oh look, complicated stuff to ignore unless I have no choice. Hope I can switch Er.... and those would be? Would they exist in an environment where I wouldn't have already selected another chip or chipset? I did try to lay Thank you, yes, I am aware of that. I am also aware of the fact that you could have implemented things so that DMA was the only way to get certain data fetched. If I'm looking at a new datasheet, that is the sort of braindead stuff I have to check for before I decide to use a chip. An example would be a CPU with a high speed synchronous serial port that you had to poll in the CPU because they flubbed the interface *shrug* As I said, showing how I would think looking at a new datasheet. I would assume there are a bunch of memory mapped registers, but who Um. It's really really application dependent. 3.3 is probably pretty safe for non-battery embedded stuff. Anything less than that isn't very standardised, and you end up with a power supply that has to supply 7 different voltages. It's a design headache and a significant source of cost. Also, the lower voltages require higher currents, and its a real pain having to supply high currents at low voltages with difficult noise margins. The last project I did the circuit design for was based on Xilinx Spartan3, and it was a pain in the ass designing a PSU that would meet And some sort of interface to the outside world, yes. You won't connect the DAC pins directly to the connector. There will be impedance issues Again, I wasn't asking you specifically. I care because I don't see you having the upfront money short of a miracle, and I would like to understand ...
Seem to me Ray what you are thinking as embeddedy is a bit below the target for the OGA asic. The embedded we are talking is the the Have even tried to get these off-the-shelp x86 chipsets for a design? If your aren't talking serious volume its really hard. And in my experience with using these chips the support mostly non-existent. Or worse the rep tells you there is support but by the time you reach a real problem you already understand more about the chip than most of the FAE's and can't find (or not allowed) anyone who It works for me. I have several designs where the OGA chip would work I'm a LinuxBIOS developer. While I think this would be useful in some caes it, but doesn't really get around our space problem. The point you would want to go run the ROM is past the point where we need the extra space. Also LinuxBIOS wants to boot fast and if you leave the legacy bios in there (to run the expansion ROM) you are somewhat back This a possibility. I have a design I'm working on now with a NIOS II that is a display product. We have a custom LCD controller in there with it. We have talked about replaceing the NIOS II with an ARM9. The display controller is really simple. Basically a DDR controller and a FIFO for me to push data into the display ram. Works for our purposes but I find myself really needing some graphics type stuff such as display to display moves or some composting between display pages. It would have to be _really_ cheap though. This is all in a $15 altera part. -- Richard A. Smith _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
*nod* My experience is that support is always non-existent, for just about anything. :-P No matter what you pay for or who you talk to, it's not worth the money or time. You get any source code and documentation *nod* OGP would need 10 customers like you to make a go of this, ignoring NRE costs, which will still be huge. I hope I am too Sure. Cell ASICs fit inside that bracket easily. I looked at having one made around a year ago, and a 50K gate design was a $2.50/part in 10K lots, I think, and NRE was quite reasonable. 200MHz was quite reachable too, and the had onboard PLLs. This is one of my problems with the OGA design.. I think it's too much with too high NRE costs... Cheers, Ray _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I'll be interested to learn what you find. Last time I did that dance was a 1.5 years ago. I know some offerings from Silicon Motion have surfaced and ATI reps some of their older mach 64 mobility designs via Arrow. -- Richard A. Smith _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well, that would sound like very good news for OGP. What about the ATI ES1000? They claim it's for embedded use.. you'd think they'd be willing to sell it. Cheers, Ray _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
If it's the one they sell as "rn50" nowadays, it's basically an M6 without the 3d pipeline. Ben. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I think the word "embedded" is a poor choice for this. I (and probably Ray) think of embedded as things like a GPS, not a general purpose computer. Support is easy. Just get your VP to wave a million dollar PO in the face of their VP. What's that? You don't have a million dollar PO? No support for you. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Heh. You so work in the same industry I do. :-) There is one company that has been an exception for me though: Atmel. Atmel have dealt really well with me, and tried really hard to please me and give me useful information. They included me in the beta for one of their CPUs when it was still pretty broken, and did everything to support me. Their ASIC people took code I gave them and compiled for one of their targets to give me an idea of what would cause issues etc., when it was obvious that I probably wouldn't be able to go through with the deal. I consider most things they have done for me to beyond the call of duty. I guess it works, because I would work with them again in a heartbeat. :-) And on the other end we have Motorola. Ummmm. Enough said, I think. :-) In the middle, TI have been fairly good, but are messed up enough internally that their helpful attempts weren't as useful as I would like. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I have no problem with the idea of trying to cram a simple 2D design into a cheap FPGA and selling that as a complete solution. That was my ORIGINAL plan, in fact. We can use OGD1 as the basis for fleshing out those ideas. Imagine fitting everything into the XP6 part on OGD1. I don't know if that's possible, really, but it would be interesting to try. Minimum of what we need: - Video controller - Memory controller - Host interface Cheap things to add: - Some format conversion (8-bit emulation, for instance) - Simple bitblt engine (which gives us solid rectangle fill for free) - Hardware cursor Slightly more powerful but still relatively cheap: - Trapezoid fill (subsumes bitblt and rect and adds triangles and lines) - Fixed-size patterns (limited color tile and stipple fills) - Planemasks and raster ops I can keep adding layers on this, but you get the idea. We do one and see how big it is, estimating cost of various fabrication methods (cheap flash-based FPGA being the preferred). If there's room, add something. Lather, rinse, repeat. I forget what the XP6 costs. Perhaps someone here remembers. It's not very expensive. But what would be the demand for a card buildable on this? Here's what it'd be like: - Single head (DVI-I with analog and single-link DVI, no TV) - One DDR400 ram chip (32 megabytes) - 200 million pixels per second total memory bandwidth - 32-bit pixels only - Absolute minimal text-only VGA support - No VESA support (due to the lack of VGA graphics) - Acceleration only for bitblt and solid fill - Not much room for off-screen pixmaps - Maybe a hardware cursor I'm not even sure this could fit in the XP6 we've chosen, although there's probably a bigger (but more expensive) one we could use. Usually, more integration is less expensive, but with FPGAs, it's the other way around. Two small ones are cheaper than one large one. We could split the design across two FPGAs for ...
How big and what features are in the video contoller? I have what I think is the above + a NIOS II and an I2C controller in a cheap Altera. (I think its an EPC2 but I'll have to look) Like I said earlier our "video controller" is basically a fifo and some logic that writes the data into the DDR while not interrupting the frames clocked out to the DVI chip. We clock the NIOS at 66Mhz and using this I can throw up a 1024x768 image pretty fast. You can see the redraw but its on par with a lot of VESA screens I see. I double buffer so its not much of an issue. All the slowness is in the NIOS II. If it was an 200Mhz ARM it would be really fast. Our "Host" interface is nothing more than about 10 32-bit registers that show up in the NIOS IO space. What kind of host interface were you thinking? How big is the XP6? When doing high res video stuff >= 800x600 I think there may be an opportunity for a simple video controller to go with the various embedded cpus. The sharp ARM and the XScale we have tested both fall down at the higher video resolutions. They use host memory for the framebuffers so at the refresh of say 1024x768x60 large ammounts of the memory bandwith is spent doing video. And if you go off and make the cpu do something invovled you can get glitches in your video output. What I don't know is how big the market for something like this really is or if the next round of ARMs from various mfgs will fix the memory bandwith problem. Perhpas it only an issue with Sharp and XScale? I know that Atmel just released a newer ARM that claims 2048x2048 as its max resolution. I can't imagine that they use host memory for that but maybe. I do know that if I had such a chip and it was cheap (<=$10) it whould have had a _really_ good chance of ending up in our current display product. -- Richard A. Smith _______________________________________________ Open-graphics mailing ...
Even a relatively sophisticated video controller that supports interlacing is just a handful of counters and some fifos. For OGA, I had some ideas about making a simple programmable controller that Well, I was thinking more along the lines of a PCI controller. But you're right, there needs to be a register set to control things, plus Well, if all you needed was something to sequence addresses and send I think it's probably better for us to have our own RAM. We just need to make sure there's enough bandwidth for the max video mode we want Well, you've given us something interesting to think about. Of course, of the FPGA alone costs more than that, we can't quite hit that market, but perhaps we could get that cheap with some low-end ASIC technology. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yes by all means have your own RAM. Thats exactly my point. And exactly why we have a NIOS and a custom LCD video controller rather The reason I used that number is because that is what our quote is for getting the altera in quantity. So there's at least 1 FPGA that doesn't cost more than that. For us the chip would have to meet that, be cheaper. or offer enough additional functionality that we would pay the extra for. Our products will ship with an altera on them. Would the DDR be inside the ASIC? If so then that adds a few more bucks. All I'm pointing out is that I've got something similar in a small and cheap FPGA. If you were to swap all the logic used by the NIOS II CPU with video functionality logic I think you would have a pretty darn nice video controller. Well, at least it would meet my low-end display needs. I'm not sure my needs match the mass market though, and at $10 you would need to sell a whole bunch of them to turn any real profit. -- Richard A. Smith _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
It would certainly make me feel a lot more comfortable that OGP will get I like this idea. It's not flashy, but we'll always have something that could go out the door if a customer appeared. Just looking at the features you are talking about adding in layers, I'm trying to imagine the kinds of things people want to do. I'm thinking mostly custom GUIs, with some scrolling, buttons being "pushed" in an out, but not a whole lot in the way of moving windows around. I think scrolling is probably very important. Here is an idea that has been done multiple times over the years. Why not have a simple display description language so we can avoid copying data? The idea is that if we have spare bandwidth on the DRAM (enough to compensate for frequent non-sequential address changes), then some sort of simple structure could be used to represent the screen display, and the RAM could be read out nonlinearly at display time. So, instead of drawing a frame by reading a linear buffer, and competing with that when blitting, we make the display counter hop around to find the data. This would allow really cheap scrolling and could replace blitting a lot of the time. The display language could be as simple as "address, count" repeated over and over, meaning fetch "count" pixels from "address". That would allow scrolling any part of the the screen in any direction with relatively few updates to the display list, or would allow replacing one bitmap or framebuffer with another by changing some pointers. If someone wanted an 1024x768 linear framebuffer, they could just have one entry in the display structure saying "addr = x, count = 786432", and treat address x as a linear framebuffer. I haven't looked at DRAM for quite some time. Would the latency on I'm not sure about desktop systems if it's just 2D and based on a $30 FPGA. I'm not sure how much the final card would cost. One "special" feature could be enough of a differentiator, if I knew what it was. :-P Maybe as a PC104 ...
Asiliant is dead. And very sad too. We used to used the the 69000 and 69030 in lots of stuff. That was a great little chip. But they depended on a fab process that was phased out. For whatever reason Asiliant was unable to respin the chip on a smaller process. So it went EOL. -- Richard A. Smith _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Doing remapping is okay if you're full-screen, because you can remap by scanline, but if we're going to remap at arbitrary points in the display, the memory row miss overhead will kill us. I think we're better off just moving the data. If the chip has a blt engine, it can do that in parallel with the CPU, so it won't have much impact. I remember messing with display lists on old 8-bit computers, but I So, basically, we just have a video control program that skips the video data pointer around arbitrarily and specifies arbitrary numbers of pixels before the next command. For each jump, you'd need two words in memory. Naturally, you'd store the display list in graphics memory, because it could get huge. As we add windows and things get denser, the program will get larger and more complex, taking up a significant amount of bandwidth itself. It could easily get to the point where we'd have been better off with just doing the copies. Oh, and I'm not even counting the row misses Horribly. With these RAM chips we're using, a row miss will cost us at least 55ns. That's 11 cycles on the command bus or 22 cycles on Isn't PC104 really horribly slow? Still... useful for small embedded systems. On the other hand, the other gentleman made the point that we're talking about high-end embedded. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Would it be possible to split things up to allow an upgradable board? A basic 2D board with a socket. Want fancy 3D stuff? Plug in the extra chip. 2-3 years later plug in a new improved chip. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
A lot of people such as Ray Heasman seem to have this idea that "3D" = full OpenGL with hardware transform, lighting, programmable shaders ... This was discussed extensively at the start of the design process. The OGD/OGC are *not* intended to fully implement a complete 3D rendering pipeline. What it is meant to do is 1. support 3D/OpenGL frame buffer ops, in particular alpha blending, stencilling, and depth testing; and 2. basic "stretch an image over a triangle/quad" hardware texture mapping, not all the bump maps, normal maps, and other stuff being done in hardware for the latest games. This is more than required for classic X Windows or GDI, but it is the minimum expected for Windows Avalon or the new X11 implementations like Novell Xgl and Red Hat AIGLX. Note that the names given to these new X11 implementations include the letters GL, meaning OpenGL. The X Windows authors have already decided what hardware requirements they want from the next generation of video cards. They want OpenGL! X Windows is already being rewritten for 3D graphics cards, so designing and providing a 2D only interface for the OGD/ OGC won't make adoption any faster and might even slow the process down. -- Hugh Fisher DCS, ANU _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I was under the impression that the recent discussions about a shader were done with the intent of including one on the chip, at which point I considered how many gates we were talking about and my head exploded. I tried to check on the wiki, but it was down. That was part of the reason I was upset about 3D support. If we're trying to get things into a limited number of gates, even texture mapping is a waste, when just being able to scale a bitmap down would probably be sufficient. On the whole, I still see the idea of a mixed signal ASIC in a recent process as being a pipe dream without some significant funding that won't be coming from any of us. I'm also really disappointed that there won't be a cheaper dev card to play with. The current OGD design might be nice from a developer convenience perspective, but it sucks from the "affordable to an FPGA hobbiest that wants to dabble" perspective. Given how much time I would have to spend on playing, I can't justify buying an OGD. I'd happily settle for a cut down card that can crash my PCI bus if I screw up. Second hand PCs are free for most geeks. I'd program it over a USB port, from another machine, and be happy. I have realised that my impression of what OGP is, is wrong. It's not an open source effort to make something that lots of people can develop on and play with. It's a company that has an open source policy and also happens to have a mailing list. Traversal doesn't need everyone to have one of their dev cards, even if the card is cut down, because it's not the goal. Making something that will encourage lots of hobbiest developers to do weird things is not the goal. Don't get me wrong; I'd love to see open hardware out there. I hope Traversal succeeds. I'll buy their stuff out of loyalty if it isn't too expensive. I just think don't people like me constitute a market that can be counted on, so there will have to be a reason for the average Joe to buy it. Judging from the questions that Timothy hasn't ...
I thought it was pretty clear that the programmable shader discussion was forward-looking, hypothetical, and something that's to be experimented with on a small scale with the FPGA. I did mention that I'd be willing to entertain the idea of skipping a generation if it were necessary, but that's only if it's necessary. Also, more than once in this discussion, I referred to OGA as a "fixed-function fragment shader". That means it's not programmable. But you also said you wanted rotation. If you have scaling and rotation, then you have all the hardware you need to do arbitrary distortion. The only texture feature we have that is "advanced" is MIP mapping, but I intend to implement that with a relatively simple state machine that does sequential fetches, thereby drastically limiting the We've had ASIC vendors tell us we could do this. I don't know HOW they mean to do it, but if they can, we'll use it. Remember that many ASICs are pre-fabbed. All the silicon is done and the first few layers of metal. When ours is produced we only need masks for the last few layers of metal. If they've got blanks with DACs on them, GREAT. You've got to be kidding. Aside from one or two products that have ancient and very small FPGAs on them, OGD1 is dirt cheap. If you compare it to something even remotely comparable in terms of features and logic area, it's a steal. There may be some room for non populating some parts, but it probably This is exactly opposite of the truth. OGP started out as a project at Tech Source. They decided to drop the project, so I was left with two colleagues and the OGP list. Going it alone, I needed a name and a way to conduct business on my own. Traversal is just a front for the OGP. Companies don't do business with the Linux Kernel Mailing List, but they DO do business with OSDL. Traversal is a way to centralize business. Of course, being a business, it has to make a profit, and we may find it necessary to work on projects not ...
This sounds very very useful if there is some way to do it without using up a PCI slot. Only way that comes to mind is a combo board Too small? The firmware on my boards has room for lots and lots of This sounds promising. Add a RS-232 port. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
How much does adding useless eye candy hurt things? Transistor count? What do you recommend? ATI doesn't support sync-on-green. Nvidea drivers don't work. Other brands? Almost never hear about anything except ATI/Nvidia. Need open-source (not binary-only) drivers for at *least* the BSDs and Linux. Hardware decode of mpeg2ts, hardware scaling, High quality s-video out. DVI (preferably dual-link) or HMDI for the future. The possibility of calibrated color if I decide I need it. No fan. The ability to see what the stupid firmware wanting 640x480 is printing, using a fixed-freq or limited-multisync monitor. (scan converter? Given that FPGA is expensive and power hungry the app had better be very useful or the number sold will be very small. If the number sold is small, the profit per card needs to go up to pay for development/fab and to fund the ASIC. This was discussed a few weeks ago. Seems like a long shot to me, but I don't have insight into this market. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I'm not sure how much a shader adds, but if we want to get something out there soon, and for cheap, that means a limited number of gates and little or no mixed signal component. That might not be possible at all in the desktop arena (people will want their analog outputs). In the embedded arena, it might not be that bad to have just digital outputs, and it could be done for an order of magnitude less money than something that is too big to fit in a cell ASIC and that requires mixed Well, if OGP had the sort of lock that Intel and Microsoft have on their industries, along with attendant network effects, I think you would have This part isn't talking about market. It's talking about generating the kind of excitement and immediate usefulness that means people want to play with it and will hack your code for you. It sounds like Timothy isn't depending on that - I think he's just hoping to take advantage of other open source companies rather than general excitement and development work in random open source developers. Cheers, Ray _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well, what got me excited in the first place wasn't the idea of an Open Graphics chipset but the idea of an Open company like Transversal. Everything happens in the open with this company. At the time I might be interested in one of their products (I'm not at that point yet) I know I will have the possibility to at least convince them to include something that *I* need and not only stuff that generally is considered useful. Erik _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
But, those developers wasted their time re-writing support for cards that darned well ought to be available. I would prefer to see them spending it on something more useful, like maybe porting SDL to the new PS3 Linux platform so it will run PyGame games that I write. I know that it doesn't exactly work like that, but time-wasted because of some twits hiding their specs annoys me, A factor of three is pretty good; entrepreneurship is always risky; and I think you're underestimating the odds when one of the "business relationships" Timothy is talking about is probably his current employer, who is apparently pretty supportive of this project. Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I need all the things you need, and I need 3D. Specifically, OpenGL. For the
following things, all of which require OpenGL:
- CAD (e.g. ProE's features):
- Solid modelling/moulded parts
- Sheet metal parts
- Antennae (some of the latest tools show the generated
field in OpenGL)
- Mechanism design/animation
- Open-Source 3D art modelling (Blender, etc)
- Playing Open Source games (Tuxracer, Quake I/II/III-based stuff, Cube...)
And I want my 3D card from a vendor who does more than pay lip service to
support for free operating systems, and provides proper documentation, so
that the open source drivers don't suck.
I also want the ASIC product for incorporation into embedded systems. I can
think of many applications for such a product.
But I don't need all the latest per-pixel shaders, blah blah blah that the
latest ATi/nVidia cards boast about. OpenGL 1.0 is more or less enough
(well, maybe there are some 2.0 features that I need, but I can't think what
they might be).
I can't afford an OGD board. But I sure as hell will buy a OGC if and when it
arrives.
Peter
--
Quake II build tools: http://peter-b.co.uk
v2sw6YShw7$ln5pr6ck3ma8u6/8Lw3+2m0l7Ci6e4+8t4Eb8Aen5+6g6Pa2Xs5MSr5p4
hackerkey.com
_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I think the "3D GUI" argument is a bit of a cop-out. I think what OGC is really doing is trying to avoid having to go head-to-head with the latest and greatest 3D proprietary card. With the market realities of today it is unlikely that OGC will be able to compete with the hottest new games running on the newest accelerated video system. This is not really something I care about, but I can see reasons There's always going to be some new bleeding edge thing out there, and as things stand, you won't be able to catch it with an open hardware project -- not with the way the production Hmm. I'm a latecomer ... what's the difference between "OGC" and "OGD"? Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
OGC is the name of any graphics card based on OGA. OGA is the graphics architectural design we're working on. OGD is the FPGA-based development platform that is being worked on right now. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Almost. OGC is the part number prefix for ASIC-based OGA cards. The production series, in other words. There's a nomenclature page on the wiki, that the FAQ points to, but it's kinda hard to find. I forget how I got to it last time. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I guess I oversimplified. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This certainly a valid concern. Specifically, we do not want to build the bus interface into the chip. Currently we would need support for AGP and PCIe based MotherBoards, but we have no way of knowing what we Yes. I would advocate using existing ASICs where possible and CPLDs for I am also concerned about that. We need to consider how to amortize one time costs, and where the break even point is. Unless we can get VC backing, I think that we would have to break even at 5,000 units which This is a valid point but ... . We can compete with commodity items as long as the commodity items have closed source drivers. However, we can only compete on this basis with Linux and BSD users. If the design is done in Verilog (or other VHDL), there isn't really a question of hardware generations with the design. The issue is that newer hardware generations are going to cost more money to implement. So, being one generation behind is a reality that needs to be considered. Can we get the performance we need with 65 nm or do we need Hardware OpenGL is what is needed for some users. Actually, it doesn't need to be OpenGL, but rather just needs to do the parts of the SGI This is something to consider. While nVidia and ATI do not actually make native OpenGL cards they do dominate the market to the detriment of Yes, I agree that there is a large market that doesn't need hardware 3D This idea clearly has merit. However, we still have the same issue: do we have hardware 3D acceleration? Perhaps we should have a card design that offers it as an option. If the card has only a generic pixel pipeline and the OpenGL parts are in the diver, it could be used for both the new X and OpenGL. We should also consider if the 2D hardware I have not experienced what you are talking about but I do experience what I think that you are complaining about. IIUC, this is not a function of the graphics card but rather of the way that *NIX does multitasking. UNIX will ...
Ever since linux-2.6 came out with preempt, my GUIs have been running happily smoothly. Justin _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Somebody pointed out to me yesterday that a mask set for a 250 nm process isn't $2M, it's $50K. And that's on SOI, which is much faster than a normal 250 nm process, because it eliminates isolation junction capacitance. How much logic is the TRV10 going to need? Could it be implemented with an older CMOS or SOI process that doesn't have such prohibitive up-front costs? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I'l have to let Howard answer this one. He contacted ASIC vendors and priced them out. If I understand it correctly, your $50k NRE costs less up front but more in the long run. Oh, and it's not $2M for the NRE. It's $2M for a 100k unit production run. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
It probably will fit on a large 250nm die. However, 250nm is quite slow, power hungry and there are end-of-life issues. A good compromise would be in the 130nm to 180nm range, where mask sets are in the order of a few hundred thousand dollars. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
For slot based cards, "currently" would include PCI as well as AGP and PCIe. It appears that OGD1 will be PCI-X for some reason. I hope this doesn't My crystal ball says AGP will go away very soon. My crystal ball says PCI will go away, but slower than AGP. The problem will be too few slots per board. (Even worse than now.) My crystal ball says PCIe will be good for several years. The real unserved market is Ethernet, but I don't expect to be able If the design were ready today, could we even get 65 nm? Isn't AMD Is there any area where the OGC1 is faster than a Radeon 9200/9250? Solaris is some form of open source now, right? What graphics/video What versions of Unix block I/O to do other things? It is normally I/O that gets preference. If so, someone needs to rewrite the Linux Kernel. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_kayan.duskglow.com-17824-1150823027-0001-3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit if the PCI-X is properly done, it should be compatible with standard 32 especially as PCIe anything other than graphics cards seems to have you can consider solaris, and the various *BSD as distros of the same stuff :D --=_kayan.duskglow.com-17824-1150823027-0001-3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic ...
But not a PCI 64 bit slot? Most boards don't need more bandwidth than PCI allows, so almost no one bothers making a PCIe version. Newer mainboards have fewer and fewer PCI slots. Personally I don't think needing a seperate computer for every 1 or 2 boards is acceptable. Especially when they put such a small Yes, an X-Terminal that does SD and HD video as well as "desktop" type X apps. Yes, "in a few months", not today. Question is, how far behind SOTA will the process available to OGP be? No. "distros" is a Linux term. Solaris, *BSD, and other Unix kernels are significantly different than Linux. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well, I don't have them right off... they're standard for PCI-64, but that probably doesn't tell you anything. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Upon further investigation, it looks like PCI-X uses the same connector as PCI 64 bit, aka PCI wide. Assuming these are compatable, then never mind. I mean the maximum length of the card, not the connector. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Their 2D board is based on an ATI chip. I presume that ATI gives them full details. The 3D boards use 3DLabs chips. I haven't checked to see if there are Open Solaris drivers for them. My 400 MHz Linux box (with CONFIG_PREEMPT=y) stops accepting keyboard or mouse input from time to time. This happens often with Thunderbird and Konqueror but happens with other apps as well. While this happens, the disk access LED is flickering so it must be disk access that is blocking Yes, this may be needed. The major issue is that GUI apps do not run at higher priority than other processes (user apps can not be set to nice < 0 except by root). Also, the app for the window that has focus needs to have its priority increased automatically. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
If there are open source drivers for them, someone could port the drivers to *BSD, Linux, etc. Or use the info in the drivers to write BSD/Linux/etc. drivers if the licence prevented porting. It sure would be nice if Solaris, *BSD, Linux, etc. all used the I'm guessing that Thunderbird and Konqueror are large relative to the If you change focus to an app that is swapped out, it will take awhile for it to become responsive. Try running top(1) in a window and then getting the problem to happen. If it is memory/paging/swapping, you could add memory, and/or add RAID. You could look into hacking your kernel to give the mouse and keyboard a higher SPL (or whatever this is called in Linux) than disk. Standard warning: Backup your data before running the new kernel, just in case. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That's why we chose PCI-X. That's because PCI will be around a while, I don't think it's necessary. 65nm, compared to 90, buys you mostly power consumption and yield. Performance doesn't go up that much. Keep in mind that it's wire delays, not transistor switching time, It'll go exactly the same speed as any other card that has a 128-bit DDR400 memory bus. Ok, well, slower for some operations, but once you saturate the bus, the same speed. (Except for those with Z A variety of things, including this product whose X11 driver I wrote: I'm not sure what's being discussed here. Usually, you try to overlap CPU and I/O by using DMA. But the process waiting on the I/O is blocked. And sometimes, you can't do the I/O via DMA. There are also issues with the X server using enough CPU that process With a graphics card that uses DMA, you offload the I/O overhead from the CPU to the GPU, so the CPU can do other things. This has the effect of lowering the load for the X server, so it gets a higher process priority. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Assuming that one goal is to sell lots of boards in order to get Traversal bootstrapped, the question is whether you can sell more PCI-X boards competing against Radian 9250 boards, or if you can sell more Ethernet boards competing against, uhm, nothing that I've been able to find. Lots of people are looking for an Ethernet to television solution. And there will be lots more as the analog shutoff gets closer. There are products like Roku HD1000 no digital output only decodes mpeg2ts reliability problems I-O Data Avel Linkplayer2 no digital output Momitsu V880N no ts decoding PixelMagic MediaBox network streaming issues hauppauge mvp no HD and others but it seems they all have serious problems, several in most cases. And as far as I know, none do X11. I think the first box in this space that gets it right will clean up. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
hah. those. I read about a few things that will do that, however, they'd be "Windows play for sure" devices... yeah that would be awesome. the first solution to come out would storm the market in a flash. especially stuff that doesn't come out broken out of the box (read without funky PITA DRM attached) of course, there are others in the pro space that do that. but we're _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That is what nVidia is currently doing, and it can have performance issues. 65 nm gives you shorter wires. Are they faster? The issue that I have is when either keyboard or mouse input is blocked by other processes. A secondary issue is when a redraw has to wait for another process. Some of the time, I presume that it has to wait for a With a graphics card that runs the X server, you would offload even more overhead. :-D -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Oh, I know. But I'm counting on using DMA so heavily that the extra I'm not sure. I think the capacitance goes up, taking away some of Linux has a problem that Solaris resolves. Under Linux, the mouse driver talks to the X server, which talks to the graphics card. If the X server is heavily loaded, the cursor skips around. Under Solaris, the mouse and graphics drivers have a standardized interface that allows the mouse driver to talk directly to the graphics driver, True, but if it's X11 that's swapped out, at least we can deal with True, but is it worth it? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yes, just scaling doesn't achieve the expected proportional increase in speed. That is why there is talk about lower dielectric constants (using other things to replace Silicon DiOxide) and using Copper conductors for interconnects. τ = R*C so reducing R does just as much good as reducing C for the initial charge of the line (if unterminated). But the initial charge time is determined by the propagation speed as a transmission line and only reducing C will help. Z = (L/C)^2 but the speed of the line is determined by C -- larger Coax has a faster propagation speed because it has lower C/meter. Another problem is that scaling implies narrower interconnects which means less inductance and a lower line impedance. Simple solution is to not shrink the interconnect width but then the chip doesn't shrink as much as you would expect. Don't know for sure. This would be a unique product. Although I note that this wouldn't be a totally new idea. TI was pushing this idea although I don't think that a commercial product ever made it to market. DEC used to sell workstations which had a separate processor to run the X server. IIRC, this was not nearly as powerful processor as the main CPU. IAC, it seemed like a way to proved the "Amiga like" performance. Since the only thing that could slow down the mouse and keyboard input would be PCI bus contention and the X server would never be swapped out since it would have its own dedicated memory space. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That would actually be pretty cool. It would keep X from competing with ordinary application tasks for resources, which is often a source of hang-ups or slow performance on typical single-CPU Linux desktop machines. It might be more practical to just go to dual processors or something, though I've never attempted that. An X server in hardware though, as a simple drop-in system has real potential, I would think. Would you then support the pointing device through the same card (seems like you would). Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Seems to me you'd want to make the card almost a small computer (For flexibility). Say an embedded PPC or something with built-in fp, and a coupled GPU. Making the X server completely HW (i.e. the X in the FPGA) would be pretty expensive by the time you got an FPGA big enough & fast enough to run it wouldn't it? Especially since you'd have to allow for several years of bloat in the code as you update to get the latest X features... Hey! You've re-invented the X-Terminal! NCD would be proud... H -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmmCf/3QXwQQkZYwRAgstAKDUkxVZXgpjmFqTJym6BWVqwaLeIACfV1uS dBfrO/8mTWVmf5qsZrNQXUE= =rT01 -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yes, that's my impression, too. Ah! I should remember my audience when I speak. ;-) When I said "in hardware", I just meant on the daughterboard in the PC -- I'm sure the X server would be running on a fairly standard embedded CPU. You'd just have the OGC chipset set up as *its* display adapter. I wasn't talking about implementing an X server in an FPGA (that sounds terrifying!). Undoubtedly, you'd be running a small Linux or FreeBSD on the X server card, and X would run in software on that CPU. Of course, you'd want to have a simple pass-through to allow text-mode display from the main system (this might require some magic, but the idea is that it would allow you to get to your system if the X server had a problem. You'd be plugging your keyboard into the X server, though, so you could catch a special keystroke or Yeah, it's basically a thin-client built into a standard PC daughterboard. I don't know, it'd probably cost more than it's worth (sorry but I'm pretty clueless about estimating hardware expense), but it was an interesting thought! :-) Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Standalone X terminals are very nice because they are quiet. Put the noisy computer in another room and shut the door. Putting a dedicated general purpose CPU on a daughter card just for X11 is probably less than optimal. Instead, get a X2 chip, and if X11 isn't using a CPU it is available for other tasks. You can get a used standalone NCD X terminal pizza box for US$5-10. Add standard monitor, keyboard and mouse. Works great for "desktop" type work. I haven't found a way to shoehorn TV style video into one though. What I'm looking for is a similar box that is fast enough to do video, and can output to either a computer monitor and/or s-video. I've been thinking about what it would take to do that, and do it right, and it does look like a larger project than the PCI card version. I've been thinking about starting a requirements doc for such a box. A significant problem is that the feature list quickly explodes to the point that it is a full blown computer. Which means expense and noise. Question: does anyone have a good feel for how much general purpose CPU such a box would need? Everything I've read says that H.264 needs a massive amount of CPU to decode, even with recent GPUs from ATI/Nvidia. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Heh... you're not going to do H.264 without a full-blown computer. Theoretically, a hardware-accelerator could do the job on a slow machine, there just aren't any 100% hardware H.264 decoders yet (probably never will be... general purpose CPUs tend to catch-up). You _can_ do ffmpeg or xvid style MPEG4 with a Via mini-itx board and specific graphics drivers. You could also do MPEG2 with something like the MediaMVP (http://www.hauppauge.com/pages/products/data_mediamvp.html) for which there exists a replacement firmware which utilizes MythTV (http://mvpmc.sourceforge.net/idx.php?pg=main). --tim _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Personally I don't need H.264 yet, but someone probably does, and it I'm hoping to get *away* from ffmpeg, and use something that actually works Looks like they are making some good progress. The MediaMVP output is SD only, not good for long term. It could be a nice short-to-medium term solution while we wait for prices of HD displays to come down, except I haven't seen anything about HD, so I assume it doesn't have enough power to input HD and scale it down to SD for output. A lot of the OTA shows are HD. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Sure. There is, however, quite a bit of uncertainty in the next-gen consumer video encoding space I think (what with Microsoft's attempts to push WMV, H.264, Bluray and HD-DVD (yes I'm mixing encoding and medium a bit here, the two interact somewhat), Dirac, etc... not to mention the continued development of the MPEG4-based codecs (of which Huh... It's worked great over here. I would _really_ like to see a Ummm... Yeah. HD->SD conversion is even more intensive than HD decoding (think decoding plus resizing). That is, unless someone's snuck in an ingenious algorithmic trick that can be used to pluck an SD stream out of an HD one... which I suppose is quite possible (I certainly wouldn't know). Back in the day... HD displays had nice interoperable inputs like DVI and 15 pin VGA. Those were nice - hook a regular computer directly up to the display, select the correct resolution, you've got yourself a programmable TV. But apparently we're all pirates and can't be trusted with devices that actually talk to each other. --tim _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
There are at least two separate problems resulting in segmentation faults. And at least one resulting in floating point exceptions. And that's just in the mpeg decoder. It doesn't get interlace right. It doesn't understand I read somewhere about some encoding that was designed to allow this. ??? Might need a DVI to HDMI adapter, but I haven't heard of any HD displays that can't be connected to a computer? The problem I've read about is the other way around. Blu-Ray, HD-DVD, cable-tv boxes that refuse to output HD unless the display has HDCP. A pirate commits armed robbery on the high seas. Copyright infringement is wrong, assuming one can figure out what is and is not "fair use", but is hardly comparable to armed robbery. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't know about you guys, but if someone takes IP we release for this project under GPL and puts it into their own chip without either paying for it or releasing the rest of their design under GPL, I'm going feel personally insulted and cheated. Not to say that I don't expect a certain amount of piracy, but the one idea behind releasing it under GPL is that you CAN try it before you buy it. The instant someone else starts making money from our work here without us benefitting from it, that's highway robbery. It's theft not only from those who worked on it directly but from the community as a whole. How I feel about someone downloading songs from the internet depends on how they dealt with their downloads later. Were they trying to find out what they liked? Did they delete the MP3s they didn't like? Did they buy legit copies of the ones they did like? The fact that the RIAA is evil does complicate matters. But I also don't pirate Microsoft stuff. To some people, they feel justified in pirating commercial software on the grounds that proprietary software or some given vendor is evil. I don't. If I want it badly enough, I'm going to pay for it; mostly I just avoid it entirely. To me, copyright is our friend, because it's what protects our GPL'd works from being pirated by companies that want to benefit from our work without giving back to the community. That copyright law doesn't apply only when I want it to and not apply when it's inconvenient. I've never bought into those arguments that it's okay to copy digital material because it doesn't cost any extra just to make a copy. Oh, I agree that it's hard to put in the same class as, say, a Fabergee egg or something else with tangible presence. But the work and craftsmanship that goes into developing a good piece of software should be shown no less respect than what went into a piece of art. Being easier to copy doesn't enter into it. Should we be allowed to make and distribute as many copies as we like of a ...
If someone takes IP from OGP and makes and sells a competing chip without following the rules, that is clearly NOT fair use. It is wrong, and they can be hauled into court and punished for it. It is a copyright violation. It is not "robbery" or "piracy" or "child molestation", or "terrorism" or whatever emotional term someone wants to label it with. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
"Piracy" now has a meaning different from historical usage. It would be a metaphor to use the word "robbery" if robbery requires that one steal something physical. Maybe it's closer to espionage, because it bears resemblance to infiltrating another country or company and leaving with ill-gained knowledge of secrets. Referring to "child molestation" and "terrorism" is hyperbole and an attempt to villify piracy more than necessary, as well as taking away from the impact that those ideas have in their proper place. Someone who steals property (tangible or not) should be sued and/or fined. Child molestors and terrorists should be dealt with much more harshly. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
"Piracy"... Much to my surprise, my big unabridged dictionary lists copyright violation as one of the meanings of the word "piracy". Goes all the way back to the 19th century. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart1274496.hPJa2cnyMX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ah... Aren't Picasso's out of copyright? I though he'd been dead for long=20 enough that copyright had expired on his works... Not trying to start an argument or anything... Just my usual pedantic self. H --nextPart1274496.hPJa2cnyMX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEnGJTwRzSEdQQDooRAv7mAJ4ufRslBZSfx0c81VK6ti+PaPY0YwCeLkr2 aMy71EC3Dos0MJks7+FBwTU= =gjEQ -----END PGP SIGNATURE----- --nextPart1274496.hPJa2cnyMX--
True, but that's a nit-pick. What if you could sell artwork for thousands of dollars, were it not for some jackass who broke into your house, borrowed your painting, scanned it, posted it on the internet, and returned your original? Anyhow, we should probably limit this discussion. I think we're all in agreement that DRM is evil, fair-use is important, and the RIAA doesn't give a damn about the artists that it's ostensibly suing people on behalf of. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart6069414.WAbT8Zt8EI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yeah, sorry it was a nit pick... But I still don't like the analogy... WIth= =20 Art originals are almost always (OK, I'd go for always) prized more than=20 reproductions (Copies).=20 With chips that can be true... Except the law seems to be a bit fuzzy there= =2E..=20 I've never understood how the US Govt could have a decree against IBM when= =20 they had a monopoly that MADE them allow MVS etc to run on Hitachi/Amdahl e= t=20 al, and MADE them make hardware compatible etc, yet can allow lawsuits=20 nowadays because people are trying to make things compatible because someho= w=20 Yep. Apologies... DRM just makes everyone mad I guess... H --nextPart6069414.WAbT8Zt8EI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEnIKvwRzSEdQQDooRAgfsAKCm50AM0XylnCQyUin6Wlcr9P1HKACgweM3 VyT5HWvAxHkVMYKXrctYp9s= =QUkp -----END PGP SIGNATURE----- --nextPart6069414.WAbT8Zt8EI--
--nextPart3881543.iIGc67ys7U Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It's called bitrate peeling. There is some support for it in Ogg Vorbis=20 (used by streaming servers IIRC) but you get a higher bitrate (in the=20 original stream) and less quality (in the peeled version)... Lourens --nextPart3881543.iIGc67ys7U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEnFAdvmNyqZHWDvURAqnyAJ9qIHhQhTLBwR0YsnHILsUpsZ22PQCgt9I2 N0dCjhdQxZkYzIQBsxufT4A= =KkD5 -----END PGP SIGNATURE----- --nextPart3881543.iIGc67ys7U--
I think the only thing ffmpeg doesn't currently support in terms of h264 decoding is interlacing, of which all methods aren't yet supported. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 heh... yeah... Trying to understand verilog well enough to draw a line Hmm... It might not cost more than it's worth though... Consider, it'd be standard, well known hardware, open, so completely understood... No multitude of workarounds required because one card works slghtly differently from another... It could be really useful... Especially if the OGA ASIC can come in at a pretty good price... Hamish. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmtun/3QXwQQkZYwRAiQVAJ91SpC0tChpYByClrSDLm9kkS9TnwCfZAor ssIZVEExZhxKBdqU10Pk9Hc= =SzXN -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Yes, you would need some minimum Linux to support the X server and Yes, you would need VGA hardware that would be the default on reset till Actually an AMD Geode-GX is in the under $30 range and includes VGA hardware and some basic 2D graphics functions. The problem is that the only way for a graphics accelerator to access its memory is through a 66 MHz 32 bit PCI. Clearly this could be bottle neck as it would also be the interface to the main PC unless the Geode serial connection would be faster. No heat dissipation issues since the 400 MHz is only 1.1 Watts. The other alternative I can see, using existing parts, is to use an Intel NorthBridge chip with graphics built in, with a processor and the graphics accelerator sharing the front side bus with a CPLD to control this. Interface to the PC could be through the north bridge's I/O bus where I would use an existing PCI chip or a CPLD. Under 1GHz Celerons are cheep, the only problem is that they need a heat sink and a fan. AMD doesn't recommend Durons for new designs. AMD Geode NXs are low power and have been upgraded by AMD to include some Athelon features. The 1 GHz is only 6 Watts so you might need a small fan but no large heat sink. Unfortunately, these are new and (therefore) aren't cheep. Both possibilities leverage existing hardware to do the video output and the memory controller so the ASIC doesn't have to do that. In either case, you can have two price points. Either with or without the GL hardware accelerator (this would be real simple with the Geode-GX as it could be a PCI daughter card). The Geode or NorthBridge would have some basic 2D acceleration. You could also offer the NorthBridge without the CPU (no X server on board) but you would need some sort of very low performance CPU to boot the card -- read a ROM (or possibly from the PC's memory) and configure the NorthBridge. Intel's DOX state that the NorthBridge can only be configured from the processor bus so you ...
What? You want to reopen the windowing system competition Heat sinks are reliable, quiet, and don't use power. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Dieter wrote: Yes, but ... (TM) Heat sinks for most CPUs are also *large* and IIUC we need to fit this on a PCI board. I said no _large_ heat sink not no heat sink at all. Yes, it would be best to do without a fan, but many graphics cards do have small ones. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Ah, it sounded (to me) that you were suggesting a fan *instead* of a heat sink. The real problem of course is that the PCI card form factor was not designed with cooling in mind. The bus connector and I/O connectors should be on opposite sides, not adjacent sides. Then you use one big, slow, quiet, energy efficient, monitored, standard-size-easy-to-replace-when-it-dies system fan to cool all of them. Kinda hard to fix that now though. Is the Geode due for a die shrink? Can the Geode be underclocked and still be fast enough? I'm guessing that it is way faster than you need for desktop, and way slower than you need for video unless the GPU does 99.99% of the work. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I have found no specific information, but everything seems to get shrunk if it is an on going product. AMD says that this will be a 10 year product. So, if it doesn't get shrunk somewhere along the line it is They make slower ones but the slower NX (666 MHz) is still 6 Watts. AFAIK, they are static so they will run at lower speeds but 6 Watts appears to be the static power -- no power reduction in dissipation with a slower clock so no real reason to run it slower unless the bus speed is an issue. Faster and power is an issue. The 1.4 GHz one is rated at 14 Watts and AMD says it needs a fan. As I said (poorly) before, the 1 GHz wouldn't need a fan unless the tight space on a PCI board made a small one necessary. And I forgot to mention that AMD does support Linux on the Geode processors. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Perhaps you want a GX2 rather than a NX. I've got one on my eval board and its nice and peppy. Needs _no_ heatsink and newer linux kernels have framebuffer support. Thats whats in the OLPC. -- Richard A. Smith _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Is it fast enough to decode, scale and display video? Say, mpeg2/mpeg4 SD to/from HD? (h.264 is way too much to ask.) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This may be hefty for software to decode, but what would it look like in hardware? Talking about JUST decompression, what's the algorithm look like? Let's lay out the pipeline. I'm sure there's some matrix math and some trig going on. The former uses multipliers, and the latter uses look-up tables. What do we have to do? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
IIUC, GX2 is a National Semiconductor designation. NSM sold the Geode product line to AMD and they don't use that model number. I think that a AMD GX is the same as a NSM GX2 but I am not certain. The AMD GX has one limitation: its I/O is a 32bit 66 MHz PCI bus and a GeodeLink serial connection. This _might_ be a bottle neck for running a hardware 3D graphics accelerator with it. IAC, I was suggesting the NX to be used with a NorthBridge with Graphics such as the Intel 945G where the GX with the built-in VGA would not be suitable since you don't need two sets of video hardware (unless you want two screens where I would suggest that two cards are a better solution). The GX would be a very good choice for a low price point graphics card. The low power and no fan (might need a small heat sink on a PCI card) are definitely needed features for a graphics card. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
A common thing with AMD is that they specify max TDP wattage for a whole series/core, and the logically will be based upon the fastest one of them. So it is very likely that the slower parts that specify same wattage actually will require far less. -HK _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
With the exception of some pathological things (like PolyPoint and hitting against some of mi's O(n*n) or worse span rasterizing code), most things can be quickly dumped into a DMA buffer and shipped to the GPU while the X server sleeps. The reason for the high CPU usage is drivers that try to render mostly using PIO. I've looked at the Radeon driver, for instance, and it does everything but PutImage and GetImage using PIO. Our plan is to rely on DMA almost exclusively. With properly-written Well, a dual-processor system has historically been a lot more expensive than a single-processor system. What with all of these 2x processors now, that's changing. But you shouldn't throw hardware at something as a solution to bad software. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't think this is a stock OGC card that I'm imagining. It's more like an embedded computer with OGC chipset for graphics (see other reply). I'm just applying "separation of concerns" to making the system more robust. With a separate CPU running X, there's less chance of a crash in one application hanging X, or X hanging everything else. ISTM that recovering from faults would be easier, and there'd be fewer faults to begin with. You can, of course, get this arrangement with an X terminal approach, but it takes up a lot of desk space. An X terminal on a card might have some uses. Interesting thought -- could you run two or three of them? Obviously you'd be constraining the terminals to be pretty close together, but that'd be no problem in a computer-lab setting. This is basically getting into competition with "thin clients" -- but unlike the thin clients, it wouldn't require separate cases, nor would X have to run through ethernet lines (communications would be on the video bus (AGP, PCI, etc), which is very fast compared to any serial ethernet link). IOW, it's probably cheaper than a thin client and would have higher performance (except for the difference in production runs, I suppose). Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I'm just boggling at concerns regarding cost of the CPU, cost of a PCB for it, cost of the memory to run X11, poor economy due to poor integration (more chips often means more cost)... It's a matter of making the added hardware costs worth while. And keep in mind how long it's taken us to do OGD1. I don't even want to THINK about another board right now. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The primary benefit from an X station is that it's a stand-alone network device. You don't need much of an OS internally. The rule of thumb with hardware is to do as much as you can in software. That doesn't mean to overload the CPU, but if you cut you die area in half by offloading some things to software, costing you only a few % CPU load, that's a HUGE win. A lot of what you do in the X server doesn't require much CPU time. For instance, telling a GPU to draw a filled rectangle doesn't require much computation for the CPU. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
So, using a $20 CPU to do some things with software would be cost IIUC, the primary benefit of a separate CPU for the X server is not that it greatly reduces the CPU load but rather that the X server can always run -- can always access the graphics hardware -- since it is never blocked by another process running. There is some benefit in speed -- the slower the main CPU, the more benefit -- but I can't see over 20% even on a 500 MHz system. Perhaps of very small benefit is that it would probably have faster access to the graphics hardware than going through PCI (or ISA, PCI-X, AGP, PCIe, etc). So, as I said, you don't need a powerful processor just to run the X server. OTOH, and not relevant to the smooth user input issue, is that you could also run Mesa on a separate CPU in which case you would need a more powerful processor. This is probably a relevant question when it comes to performance/price: can dedicated ASIC hardware run faster than a dedicated CPU costing about the same? The presumption is usually that it can. Or, perhaps a comparison to more than one dedicated CPU. Is someone credited with the law that states that 4 500 MHz CPUs cost less than 1 2 GHz CPU (I first saw it with much lower speeds :-))? I also notice that this law is also breaking down and doesn't seem to always be true except that the idea of multiple core processors appears to be based on it. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
One of the fundamental concepts behind a modern OS is that you shouldn't need the extra CPU for extra I/O-related activity. Ideally, X11 should use a minimum of CPU time and only get the CPU when its I/O slave needs more data. This isn't reality, and it's another reason why leveraging the fast main CPU can be very helpful. How much benefit do we really get from ToE? I'm sure that offloading TCP/IP is much simpler than offloading X11, but if ToE helps a huge amount, then offloading X11 will help even more (assuming the relatively slow embedded CPU doesn't become a bottleneck). Also, we may want to think it in terms of something like TuX, which did zero-copy static web serving, offloading the dynamic stuff to a userspace server. Can we code an X server that minimizes the CPU overhead for MOST operations, while letting the host CPU work on the rarer but more difficult ones? Would we really need any special And we come to a critical issue for OGA. We have only the fragment pipeline. We are relying the host to do the vertex processing in order that we could make a cost-effective design. We MUST rely on the host CPU. But you're talking about something different. There's OGA with "3D graphics", and then there's the idea of an embedded X server that only does 2D. Two different problems with possibly two different Where you end up incurring costs can surprise you. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't see that offloading the X server would be difficult. Isn't it already designed for the client and the server to run at the opposite ends of a communication link? And with a _minimum_ of a 33 MHz 32 bit PCI communication link, we are going to have rather rapid communication between the client and the server. The only thing that I would need some more info about is how much of an OS is needed to support running the X server. With Linux, I am presuming that you would need the Kernel with not much installed in it. The only things that it will do is communication with the client and swap to disk. Then there is this DRI stuff but that must also work with the client and server separated. Swap space is an issue. But I would think that giving it its own swap partition would solve that. The system bus can arbitrate access to the disk. How do you tell Linux not to swap out the X server? Only swap out the screen image data! -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
The comm link doesn't have to be all that fast for desktop type apps. Video of course needs more. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart5733267.ZLk6rXFmgF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline A copy of an embedded linux distribution is a good start. About 4-8MB=20 probably. In fact I know it can be done in 16MB with room to spare (e.g.=20 Zaurus), but that doesn't include fonts etc... You'd want to do something=20 clever there, like local fon'ts from a fontserver on the main CPU. Hamish. --nextPart5733267.ZLk6rXFmgF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEnqbNwRzSEdQQDooRAoRWAJ9ks6T3GLvdrkHRJI/DNC+y7xZtwgCgpZnm m8/ZbhRwwlkE1nADfbocipk= =AlCK -----END PGP SIGNATURE----- --nextPart5733267.ZLk6rXFmgF--
The usual reason is that you can't *get* a 4x faster CPU. There is more than the cost of the CPUs themselves to consider. Building a SMP machine and getting it right is non-trivial. Also, there is overhead. 4 CPUs don't give you 4x the performance. The more CPUs you add the worse it gets. If you have a single-threaded app the extra CPUs might not help much at all. There is another quote about crossing the prairie with four strong oxen pulling your covered wagon rather than 1000 chickens. But get it right, and doing something that parallelizes well like My understanding is that they have hit a major speed bump, so making CPUs faster is very difficult right now. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sun 3/x series... Usually a 68020 IIRC. I had one for ages, just running SunOS4 & an XServer. Purely used as an XTerminal. Dirt cheap at the time too. But they did only do 1152x900 or some strange resolution (Can't quite remember what the vertical was). They were also (Usually) 256 colours (8bit lookup table), and 60Hz. (Although IIRC we did have a couple that were more colours, they were an expensive graphics adapter. They weren't exactly speed merchants though. Even at that low resolution & colour depth... No eye candy either... Opaque wndow dragging would really kill them. I think NCD used 68k's as well. Also fairly low res (For nowdays). But did go a lot quicker, probably because they really were dedicated... Even so, my 5 year old laptop with 1400x1050 32bit colour, un-accelerated graphics (r128) under Linux is several times faster... H -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEm7X0/3QXwQQkZYwRAgxJAKCZDhO7Ksh4P0lAmpd7xh6RNAj1nQCfVVaZ uiCr1pz8rESEM5UMzuJlyAk= =xGc2 -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I don't know that Sun ever made X-Terminals. Although you could argue A 5 year old laptop is a LOT newer than a 68k based NCD. I think the 68k based NCD came out approx 1986-87 or so? Electronics makes a lot of progress in 15 years. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart5126712.qTDymGEPJL Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline That's exactly right in fact... The Sun 3/xx's (e.g. Sun 3/50 3/60 & 3/80)= =20 WERE originally sold as workstations (Diskless & with disk). However when w= e=20 bought them, the Sparc 2 was all the rage, so they were flogging them off=20 Umm... They were still selling them in 1995... And yes I know they were old= =2E..=20 That was point... I thought... H --nextPart5126712.qTDymGEPJL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEnC1TwRzSEdQQDooRArCKAJ4rpgiOKC+ndHBdsw9Srl6FpdijGwCfYHal NXSkr1PswCL3IBzlwAT7VXU= =+fjd -----END PGP SIGNATURE----- --nextPart5126712.qTDymGEPJL--
I didn't know they were still selling the 68k models in 1995. I thought I think the point was from James: } So, as I said, you don't need a powerful processor just to run the X server. And James is right. You don't need a CPU that is powerful by 2006 standards to run the X server, at least not for "desktop" type apps. What I don't know is how much CPU will be needed for video. I don't have a handle on how much the OGC GPU will do and how much the CPU will have to do. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
SunRay One was pretty cool, although more VNC than X terminal. Done right, it may be more cost-effective to push pixels over the network than X protocol. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
As a consumer, I don´t bother to understand what´s a thin-client (X terminal or Video Network Computing) but I would be happy to have less different kind of cable to manage, and so I would want to find a flat monitor enhanced by a graphic card inside. Maybe connected to my PC with an USB cable or a Firewire or an Ethernet cable, or wirelessly. I´ll be happy to see my mobo less cluttered by all kind of slot, more compact, less heterogenous. Well, some device a little more no-brainer and a little more discrete in my living room. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
This is an interesting idea. This wouldn't be much different software wise and the main difference between this and and the video card to run an X server would be the type of communication link. We would have the minor issue that the mouse and keyboard would be on the server end of the communications link. This could probably be handled by minor patches to the Kernel a driver depending on the communication link being used (if the Kernel wasn't already able to do this). Since we don't make flat panel displays, this would need to be in a small flat enclosure that could be velcroed to the back of the display. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
One can imagine all kind of "bricolage", but I think that OGP develope some technology in first and if the developement offers to the OEMs or any industrial a way to design their products differently or in an other perspective, that could be licensed. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
snip That seems good, though, the pizza box form factor doesn´t present less cable than usual, that add an Ethernet cable indeed (I suppose that the box is connected to the monitor with a VGA or DVI cable, right ?) And finally, this is an X-terminal or like a thin-client. So, as a consumer, I will tell my wish in an other way : why the graphical card should have to stay in the PC ? Why doesn´t one put it directly inside the monitor ? Does this way require an X-server on the _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Like my iMac G3, excepted for the keyboard and the mouse, the rest is So, if it may not be possible, this is not the point. I wonder the following thing : can we route the PCI channel through an other channel ? A converter or an adaptater like in an external hard-disk (IDE to USB), thus, something like PCI to Ethernet. By this way, the computer would have two Ethernet connectors, one for the screen, one for the network and not necessarly a PCI slot inside. (And if one can or has to plug the keyboard and mouse on the screen, that will be good) Is it possible ? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--Apple-Mail-1--619061470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; The computer would not have to add to an already existing ethernet =20 port - the screen could be added as part of an existing ethernet =20 network. Or, on this MacBook, I use Wireless 802.11g for internet, =20 and can use the spare Ethernet as a high-bandwidth no-contention =20 connection to the monitor - and it could easily play very high =20 I didn't know enough about the video specs, but numbers like this =20 mean that a networked decoder is a very real possibility. Maybe even =20 wireless with 802.11g, but ethernet is a much more consistent and =20 secure standard, not to mention more widely used on desktops and =20 This is exactly what I was thinking. here is a response to luc's off-=20 A precision please, is it not like Video Network Computing ? Yes, the idea is similar to VNC, except that you could provide easy =20 3D acceleration (VirtualGL is very similar - http://=20 virtualgl.sourceforge.net/background.htm), and also support for high-=20 frame rate video. So, yes, it is very similar to that, except that each node is =20 specialized to drawing. I was thinking along the lines of just =20 sending kbd/mouse events to this "X server", and not receiving =20 compressed images back, so the network activity is very low. Of =20 course, the computer sending Keyboard and mouse events would also =20 being doing all the processing, and send X client stuff as well, but =20 it is a faster version of VirtualGL in theory. The other approach is to just have this monitor act as a networked =20 accelerated display. This could lead to video conversion on-the-fly, =20 impressive 3D effects, etc. taken from here: http://www.acme.com/build_a_pc/bandwidth.html a gigabit ethernet connection is just slow of being able to emulate a =20= full speed PCI connection, while a 10gigabit ethernet can easily =20 support AGP 4x and PCI-X, as well as PCI Express ...
--=-41Oq1W0D1uZ1R1TH02vG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Le jeudi 29 juin 2006
So, I understand that my wish doesn´t need a "special" chip which would make the relation between the PCI interface and the Ethernet interface, Of course a T base 1000 is better, is it more expensive ? Moreover, I suppose that if the g-card in the terminal has to decode, it will be a little more hot and more expensive. Anyway, can we envisage in the flat panel a board with an Ethernet connector and a PCI slot on which one plugs the g-card ? Does that require a "special" chip between the PCI slot and the Ethernet Yes, I know that the use of a hub or else would be possible. I suggested two Eth connector on the PC just for a no-brainer usability : the screen->the PC->the DSL box And here, the idea to offer a monitor with a g-card inside begins interesting when one considers this configuration : the PC->the DSL box->the screen since most of the ISP´s DSL box are more than a modem/router. As well one can foreseen that the next generation of TV will have far more logic inside, more capacities to handle graphics or codec, and maybe not so different than a terminal. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That is pretty impressive effects with NVIDIA vs without - of course, they are baised. I would be happy to run tests on my Nvidia 6800 if people want me to - just send me a link. (Side note: If it is possible, it would be awesome to have this video card be BrookGPU capable. That is a general purpose programming language for GPUs that is really fun to play with. It is also a LOT faster on GPUs that CPUs and really shows this effect. For example, it took my Nvidia 6800 GPU about 1m11sec to calculate a total of 64 trillion (or so, I still can't fully read this language. That is the right order of magnitude) floating point multiplications on a 1000x1000 array. On the same program, my CPU (Pentium D SMP disabled @ 3.0 Ghz), it took 6 1/2 hours :-). What is so great about BrookGPU is that all you have to do to change CPU/GPU running is just set the BRT_RUNTIME enviroment variable Yes, that would be optimal. I am still scared every time I look inside my computer and see the heatsink (or more like heat chamber) over my dual 3Ghz CPU. It is about 10cm on a side and appears to be solid copper, with black plastic and fans everywhere. Inexpensive, low power CPU - This could be a low-end x86, but an ARM/StrongARM/Xscale might also work. ARM based CPUs have much better SoC support than x86, but then they also often don't have a fast external bus, and are not very well supported in OS's other than Linux and CE (of course, it would be running Linux, so it doesn't really Not just the cost - The space of a connector. If everything is onboard, you can easily make everything have a maximum height of, say, about 10cm (to account for the heatsink on the CPU. Assuming that you can either bolt a small heatsink to the metal case or even use a low power SoC, you could probably half that height with a little work. Granted, the graphics card would also get hot, but it can be passively cooled through the case as well. The problem with PCI is that the boards reach perpendicular to the mainboard, so in ...
Le vendredi 30 juin 2006 à 23:09 -0400, Nicholas a écrit : no, it´s not the problem to have Eth ports on the PC side, as you notice yourself _Dieter_ even low-end PC privide one port. Rather, a chip on the PC´s mobo which route the PCI signal through Ethernet. (and on the monitor g-card, the contrary, though it could be not snip Well, for the purpose of a flat panel with a g-card, I´ve trangressed my own rule to not bother with the assembly possibilities/limitation firstly. I realise that I was focusing on PCI slot just because the g-card could be removable from the monitor, hence upgradable. But this could be I stand on the monitor side, Nick, and by "mainboard" I don´t see exactly on what side you stand (maybe the both) Beside the cost, unless a 90° PCI slot exist, one can use a raiser card Certainly the things are a little bit confused in my mind, but this kind Firewall and all, that was what I mean. I suppose that that differs from a country to an other, but there´s 5 years ago, French ISP let the consumer choose his DSL modem/router. Nowadays one doesn´t have the choice anymore, you take the ISP´s box with the triple play (Voip, TV, Internet) and optionally suscribe to a security service (AV, FW, anti-spam, and so on). All that let me suppose The really frightening thing is a compromised Cisco box, projects this idea on every ISP box which seem to be more than dumb modem/router... Do cablecos have not addressed this question ? (at least on the So the electronic is there, the displaying device differs (Projector´s lamp, CRT tube, LCD matrix, though each has their own implications) Hence, the idea of a monitor with graphical ressource inside is nearby to arise. Wouldn´t be strategic for OGP/C to provide a balanced chip + an as low power cpu as possible combination ? And why not, an fpga implementing video signal through Ethernet, which _______________________________________________ Open-graphics mailing ...
You can understand the "+" as an all-in-one chip, though I don´t want as much, but why not ? You can thus understand the "+" as a board with the OGC chip, the low CPU and so on, which I called a "g-card", and what you call a x-video server. So, this board is inside the flat panel and removable. A clueless consumer like me would consider this board as a graphical-card, just because he can remove it like a PCI card. A specialist like you would name this board more appropriatly. Note: I look the OGD1 board, there are memory, some chips and the fpgas. I don´t consider the latters as a CPU/GPU per se, hence if one put a low power CPU on the OGD board and one let aside the PCI edge, does one get the same thing that you have in mind ? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Le samedi 01 juillet 2006 à 19:18 +0100, Dieter a écrit : I'll be happy to see that. Best luc _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Some time ago, AMD sold a chip to extend a parallel bus over coax, so this is clearly possible (depending on the bus clock frequency -- IIRC, this used ECL to drive the coax :-(). The largest problem with a hardware extender would the clock sync. If the remote PCI card wasn't a bus master, it would just be slow to respond -- limiting the clock frequency or wire length. But, with a bus master on the remote end, there needs to be some interaction and the delay of the wire would limit its length. So, you would probably wind up with a software driver that would wait for the remote PCI card to respond. This is going to slow things down considerably. I can't see this being near as fast as running an X server over the same speed wire. OTOH, a remote X server that uses a plug in graphics card is something to consider. But, I see no upside to this. You need two cards and 2 connectors -- that can only increase the cost. You have two cards closely spaced creating cooling issues and memory socketing issues. The X server and the graphics system would need separate memory chips and controller -- more cost. And what are the advantages over a single card? You could upgrade the graphics hardware without replacing the X server. There might be a slight increase in speed by using separate memory spaces for the X server and the graphics, but it that matters you could do it on a single card. The only product placement I see for this would be an X server being sold to use existing graphics cards. Something that we probably wouldn't be doing since we would be right back to the same problem with drivers and lack of open hardware. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart1582631.hYpLJfMOOd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline How long a cable do you want? The pSeries (IBM rs6000) have remote IO drawers that attach via ahigh spee= d=20 serial cable. The drawers house anything up to about 10 PCI slots. The cabl= es=20 can get pretty long (i.e. in another rack, which means a few metres. I gues= s=20 the specs would be online somewhere on IBM's website. probably the cabling = &=20 devices manual. I think the trick is that you don't need to extend the PCI bus itself. You= =20 actually need a PCI Bridge that happens to have it's two halves at a distan= ce=20 from each other. Now whether you can chain a PCI bridge off a PCI slot is another matter. I= =20 don't know if you can. So I may just be flapping my jaw here... (IRQ's woul= d=20 be a limitation wouldn't they?) Hamish. --nextPart1582631.hYpLJfMOOd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEp52EwRzSEdQQDooRAk7EAJ0dFNFEOgdFwGSxvAwpsLZ7JmgVEACgvNv2 jMLwc226I3lByWmL3tYA0dg= =Se2A -----END PGP SIGNATURE----- --nextPart1582631.hYpLJfMOOd--
50-100 feet might be enough for most homes and small offices if the source is centrally located. But for larger offices, and even large homes, you could Sounds interesting. But also sounds expensive. How much does IBM charge for I think some PCI cards have PCI bridges on them? Such as combo cards with multiple controllers. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I suspect that these are 'channels' (IBM speak). That is, there is probably a CPU and DMA controller at the far end of the cable. In which case, there would be no direct communication with the PCI buses in the I/O drawer. This could be serial SCSI but this would still need the CPU and DMA. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart4704496.5klMTxhzAx Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline As another consumer, why does the PC have to stay out of the pizza box?=20 What is the advantage of this arrangement over a pizza box that is a=20 complete PC running Windows Media Center edition? I now need a PC running somewhere all the time, and I can't record video=20 with this. As opposed to say a TiVo that I can just turn on and use.=20 Yes, I'll be able to check my mail, but I wouldn't be surprised if=20 next-gen TiVo-like (or XBox-like) machines have web access (and perhaps=20 even POP/IMAP clients, but most people use webmail anyway). Maybe they=20 do already. Otherwise, I'll just walk over to the PC, or grab my=20 wifi-equipped laptop off the couch. This whole thing just seems way behind the curve to me. Yes, PCs are=20 powerful enough to have a single one in your home and let everyone=20 access it through a terminal, like the mainframes of old, assuming=20 they're not all watching HD video at the same time. But PCs are also=20 cheap enough to just buy everyone their own do-everything box, and save=20 a lot of hassle. Heck, most people these days buy a Windows PC, use it=20 for a year or two until it is run over with spyware and viruses, and=20 then buy a new one when it becomes too slow to work with. That's the market you're selling to, if you want any kind of volume.=20 That's the people whom you have to convince not to buy the kids that=20 magic box that will let them play games, watch and record digital TV=20 and movies off the internet, and lets them check their mail, and=20 instead to buy something that'll let them control the PC from the=20 living room. Sounds like a tough proposition to me... Lourens --nextPart4704496.5klMTxhzAx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 ...
> As another consumer, why does the PC have to stay out of the pizza box?=20 To keep the cost down. To keep the heat down. (especially in summer :-) ) To keep the noise down. A - it doesn't run virus server B - costs less to buy C - no fragile disk drives for the 2 year old to knock off the shelf D - cool & quiet Tivo wants a monthly fee. Tivo spys on you. Are you SURE that Tivo will let you record any show you want, and archive it? And will continue to PCs are a lot of hassle to set up and maintain. This would be *less* hassle. A *lot* less. If you want to decode HD in software you need a LOT of CPU and CPU is expensive. And uses a lot of power. If the source is HD you have to decode HD even if the display is just SD. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Personally, my proposal is just an externalization of the graphical ressource (in a pizza box or in the monitor, anyway) Moreover, I don´t think that an all-in-one product would get the favor of the consumers : the PC will stay the PC, the TV will stay the TV and a Media center will be anything else. Nontheless, an application server with some thin-client instead of a Personnal Computer (one for me, one for my wife, one for everyone) has some chance on the mass market. Though, that depends of the pipe : wireless is always appealing, but still too slow and easy to disturb, the current as pipe is an awesome solution but slow as well for the _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart3009782.nKtN2Lg1YF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Well... Someone is doing it... (All in one that is). http://www.linuxdevices.com/news/NS7551486368.html H --nextPart3009782.nKtN2Lg1YF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEpWkDwRzSEdQQDooRAtObAKCqiTLS12Hns8dTTkWMJq5xkmUxdwCgzG0H IZo+9EpAmykccS+ub04LyXo= =9/xR -----END PGP SIGNATURE----- --nextPart3009782.nKtN2Lg1YF--
Wise do it before (and Apple has his iMac on the PC side). _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart1213975.MyznS6GjEY Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The XBox 360 had some problems in the beginning, but it seems like it=20 I don't see how it's easier to install a PC, connect the extra hardware,=20 install all the software, and try to get it to work (remember that that=20 PC can contain just about any possible combination of hardware and=20 software), compared to unpacking your media centre, plugging it in, and=20 But the PC might. Or might not, in any case, you'll still need to keep=20 it patched. And generally viruses aren't much of a problem for the=20 But you need a PC with it, plus any additional software and services=20 If that happens, you still won't be able to record anything, and=20 moreover, this would also affect any device we want to make. Laws apply=20 to everyone. Well at least theoretically. And TiVo isn't the only way=20 Well, yes. So why use a PC with a pizza box attached to it if you can=20 just get a media centre that just works? Lourens --nextPart1213975.MyznS6GjEY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEpYo/vmNyqZHWDvURAgEsAJ0XQpJLWMUeKIFTFigMgEo8LidCmwCeIul5 6DSd3rULEWBsXbWRo35Vq8c= =dAnw -----END PGP SIGNATURE----- --nextPart1213975.MyznS6GjEY--
The X-video-server does not contain a tuner, and thus does not record. I haven't read the latest proposed broadcast flag law, but I assume it would not affect the X-video-server. I'm not an expert on Tivo, but I've read that the newer boxes do not function unless you let them connect to Tivo-central. I believe that Tivo can and does "upgrade" the software, whether you want them to or What is your definition of "media centre"? And where do you get one that "just works"? Hard to find anything these days that actually works properly. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart7735593.fQq1pruFSe Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline So, your X-video-server which can not record anything at all is better=20 than a media centre box that may not record some content because it=20 Okay, let me try: A media centre is a plastic box which my mother can=20 buy in a shop, unpack, and place in the livingroom. She will then be=20 able to read the manual, connect a cable to the TV, to the power outlet=20 in the wall, and to the cable or DSL modem (unless that's included).=20 She can then turn it on, and watch TV, record TV, watch DVDs, download=20 movies and music, browse the internet, and heck, maybe my cousin can=20 play a game or two when he visits, too." Another way of describing it would be "A media centre is a plastic box=20 that can do anything I can do with my new mobile phone, except that it=20 connects to my TV rather than having its own screen". (As an aside, I don't have a fancy mobile phone nor a media centre. I do=20 own a TV that's slowly breaking down, and it probably won't be replaced=20 Agreed, for a definition of "works" of "does exactly what it should do,=20 all the time, anytime". Which is what you and I would use. But I've=20 noticed that many ordinary consumers are willing to (and do!) live with=20 a much more relaxed notion of "works", namely that of "most of the time=20 does something substantially similar to what I expected, without too=20 much effort from my side". As an example, my mother complained to me that some web sites she=20 visited didn't quite work properly in Firefox. When I asked which=20 sites, she said she couldn't remember, and she hadn't written anything=20 down. She was also quite happy with Firefox (and Ubuntu) overall... Lourens --nextPart7735593.fQq1pruFSe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 ...
Such a product is probably a good idea. But, it isn't the market that we are looking at. We are looking at Linux and BSD (and maybe Solaris) users, that probably already have a PC, that want a graphics solution that is 100% open (hardware and software). Media centers are already on the market. Although, I don't know if there are Linux, BSD, or OpenSolaris based ones yet. The question we would need to consider if we were to market a media center is if it would be purchased by the average customer in preference to a Windows or Mac OS X system (yes they are coming) and what advantages we could offer. IIUC, the advantages that Linux or BSD can offer for a media center are the result of it being assembled by the user -- we couldn't sell something that was not really 100% in compliance with the law. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
A product that does exactly what it promises, and does a good job at it Does not exist. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Is this going to affect a PC that is being used as a hard disk video recorder? -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
During the previous broadcast flag hoo-ha, word was that it was the tuner that would have the limitation. I only know of one model of tuner that promised to not honor the flag. Which would have become illegal to manufacture if the law/regulation hadn't been struck down. I don't know of any that definitely do honor the flag. I suspect that most do not, but who knows? Word is that there are stations that have the flag turned on. So... if you want to be able to time-shift, you need a tuner (or 2 or 3...) that doesn't honor the flag. Attach them to your open-source computer. Time-shift as you please. It is sad that you can't just go to a store and buy a box to do this and know that it will work, and continue to work. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Not certain that I understand this. The tuner may detect this flag, but it wouldn't have any effect if the software didn't listen. Yes, DRM software could prevent you from recording it, but Linux doesn't have DRM software. The tuner outputs a data stream. If you can view it on your screen, then you can also record it. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
(Sorry, luc, for sending this to you twice :-( ) Hello, here is a little background about me: I am new to this list. I found out about this project while Googling around for hardware OpenGL acceleration for a Gumstix, and after looking at the Wiki I became very interested in it (not because of the Gumstix, but because of the concept and the fact that FPGAs are cool). I am in school, but have learned some C/C++/Java/Perl/Ruby/Lisp, and a little Verilog, as well as some circuit design. I am interested in trying to help with this project, even though what I can contribute is probably minimal. I have an oldworld Power Mac G3 running Mac OS X 10.3 (it only has PCI, no PCI-X or AGP), and a Dell XPS400 running Vista, XP, and Ubuntu Linux (with PCI-Express), if either of those would be helpful with developing anything. I don't have any experience writing device drivers, but I would be willing to attempt to learn (I read about half of Linux Device Drivers, 3rd Edition, and plan on finishing Yes, it would make sense to basically just have a monitor with an ethernet connection and a power cable if all you want is a thin client, but personally I have a desktop (The beige G3 minitower from Apple) that has switched monitors 3 or 4 times. buying a $150 video card each time is not on my to-do list. Also, other advantages of putting the card inside the PC: 1) The DVI cable has 24 or so pins on it, which is quite tough and flexible. The bus connection that attaches to the video card has 180 or more pins that are connected. If that was a cable, it would be large, hard to bend, fragile, etc. 2) Many modern video cards draw a huge amount of power. It is convenient to just attach to the PC power supply, because when the PC hibernates/shuts down the video card doesn't draw practically any power. This is also true of most monitors (they stop displaying when the signal stops), but it is convenient to have everything together. 3) Protection. I have ...
Le jeudi 29 juin 2006 à 16:51 -0400, Nicholas Sinnott-Armstrong a Ah, I understand now. Maybe I could answer to you again through the mailing list this time :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart3113922.rnyjjuRub1 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Waitaminute...what if we forget about X and make this a low-power=20 low-cost VLC box? The main reason for having a TV-Out on your PC is to play movies on a=20 big screen. There already is an open source solution to broadcasting=20 video all around your house. But you still need some kind of PC to grab=20 the broadcast off the LAN and play it on the TV. What if we could=20 replace that with your pizza box? VLC is available on multiple platforms, and can cross-code and stream in=20 a variety of codecs. The pizza box itself could be a Theora (or some=20 other chip, but if VLC is going to transcode anyway it might as well do=20 it into Theora) decoding chip plus an OGC to generate the video signal,=20 with maybe some extra logic in the decoding chip to do an OSD and=20 process remote control commands. Perhaps we could even put everything=20 in a single chip, reusing the needed parts from the OGC design. And if you really really wanted to have a desktop on your PC, you could=20 use Xvfb and stream the result as a video stream... Lourens --nextPart3113922.rnyjjuRub1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEp3cTvmNyqZHWDvURAiIWAKCEQYdfwaOB6tOtI11Bdq5b7kk+pACggics EzCg3gz7JzwMfEEZViW/Fds= =HjnC -----END PGP SIGNATURE----- --nextPart3113922.rnyjjuRub1--
What would dropping X buy us? Other than the effort of porting the X server to the box. Which will hopefully be minimal, since it will Are you suggesting that we could eliminate the general purpose CPU altogether? Can we get data from the Ethernet chip into this Theora chip without a CPU? I don't really understand your suggestion yet, but I get the feeling that it is worth exploring. Could you add a few more details? I skimmed the Wikipedia VLC page, and VLC seems to be a software media player similar to mplayer, xine, etc. I'm probably missing something. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart4397490.IyLDAek4hM Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline VideoLAN, at http://www.videolan.org. This referred to my next=20 IIRC there's a digital camera that records into Theora, but that's=20 Exactly. I'm not sure how far we can integrate this and whether having=20 everything custom is the right solution, but the idea is that we: =2D Get a Theora signal from incoming Ethernet traffic =2D Decode that Theora signal =2D Transform it into some kind of TV or VGA signal That could be three chips, or one. Documented Ethernet chips are=20 plentiful, so that shouldn't be a problem; decoding the Theora signal=20 is probably the hard part, but it could be an interesting piece of IP=20 for Traversal to sell proprietary licences for since the codec is=20 patent-free. Transforming the output of the Theora decoder into various=20 video formats is something that we'll have to develop for OGC anyway,=20 and it could probably be reused, either in the form of an OGC, or by=20 taking the logic and adding it to the Theora decoding chip. It depends=20 on how useful the extra stuff in the OGC (beyond the overlay scaler and=20 You're missing VLS, the server part of the system, which can stream=20 video across your LAN (hence VideoLAN) to VLC. At my university,=20 they're using this to stream high-quality TV streams (both SD and HD)=20 across the campus-wide LAN. My PC isn't fast enough to decode HD, but a=20 crisp and clear SD stream makes watching the World Cup much more=20 enjoyable than a noisy cable signal... Lourens --nextPart4397490.IyLDAek4hM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEqLPgvmNyqZHWDvURApaSAJ0fU57JLcfCPxxjAz2OvrFSw2L1dgCfVvO5 TO4ZeU17fKJ2FoEHigTn/Y4= =esZS -----END PGP SIGNATURE----- --nextPart4397490.IyLDAek4hM--
An encoder chip could be useful for the sending end of the link, if one Do you (or anyone) have any thoughts on JRT's suggestion of using a DSP chip? The decoder needs to handle the most common formats, mpeg at the very least, to avoid transcoding. Transcoding takes a lot of CPU, and Theora is lossy. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart76813030.3smAtHR6G5 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline True. What would be nice would be a CPU with a built-in DSP, so that the=20 CPU can handle the network stuff and OSD and so on, and the DSP could=20 do the heavy-duty decoding work. I don't suppose Sony would let us borrow their Cell design? What about something a little lighter than Theora? We don't really need=20 that much compression on a 100MBit network. Something like HuffYUV=20 (Lossless, http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html)=20 or MJPEG perhaps? Lourens --nextPart76813030.3smAtHR6G5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEqRNCvmNyqZHWDvURAlRXAJ4nz+BLpD/8TXucYt2vlR/I2Myy3ACfZU2w 1twGyqwuQhGrV40b+d55bEQ= =IHbt -----END PGP SIGNATURE----- --nextPart76813030.3smAtHR6G5--
How "realtime" does this need to be? Can we not implement the I'm planning on implementing RGB <-> YUV conversation, at least. Rather than spending bunches of CPU time doing the matrix algebra, we can do it in hardware and save at least SOME converstion time. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Timothy> How "realtime" does this need to be? Can we not implement the Timothy> networking stuff on the DSP? Realtime requirements probably vary with Ethernet chip? Nick> Well, are we still thinking about having a 1000Mbit network, or does Nick> 100Mbit offer enough bandwidth? If HD mpeg2 is the worst case, then 100Mbit is plenty. Timothy> I'm planning on implementing RGB <-> YUV conversation, at least. Timothy> Rather than spending bunches of CPU time doing the matrix algebra, we Timothy> can do it in hardware and save at least SOME converstion time. IIRC, OGC will also do scaling. Anything else it can offload? Nvidia claims their GPU does 95% of the decode for mpeg2. (page 9 of the pdf from the other day.) They claim to save 9 Watts decoding HD on gforce7 vs on CPU. (page 19) I don't see a mention of what CPU they used. If OGC can't offload enough, are there HD mpeg decoder chips that we could consider? (e.g. documented) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Maybe. How fast do we expect the DSP to be? We can play some tricks that the Linux kernel does and switch to polling (rather than interrupts) when the network load gets too high. If we're not fast enough to take the network traffic, packets will get dropped and then The engine will do scaling. No plans to have the video controller do it. Have a look at the design and see if you can suggest changes that would allow for scaling. Integer scaling (simple pixel replication) isn't so hard, but if you want smooth scaling, our video controller isn't cut out for it, so we have to use the drawing engine to When OGD1's been out for a while, and we've gotten pretty far into the GPU design, we should have a look at what kind of peripheral I/O the ASIC should have for support of things like mpeg decoder chips. This should be a low-priority item. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I suspect IBM will sell you as many as you want to buy. Although I think from memory sony have exclusive rights for a while, they'r esupposed to be available to others after a certain date (Might even have passed already, not sure, I guess I could check). Lots of info on <http://www-306.ibm.com/chips/techlib/techlib.nsf/products/Cell_Broadband_Engine> no prices but it's listed as a product... H -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEqSym/3QXwQQkZYwRAraMAKDKF+bRhSwM4WSMiCFcPFcvjhUE1wCgi6Ud kIWYNSPAJetNPYCuJspP0jw= =Ffgb -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Where's your TCP/IP stack? You won't be using a normal ethernet chip. You'd be using one with a microcontroller in it and a tiny network stack. Any other chip requires a CPU. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--nextPart2800058.kr7hu27l8v Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Conveniently swept under the carpet :-). You're right, I thought of that=20 too after sending. We may not need TCP though, just UDP, unless you=20 Do these exist? For a reasonable price? I looked around for a bit but=20 couldn't immediately find anything... Lourens --nextPart2800058.kr7hu27l8v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEqRFCvmNyqZHWDvURAli+AJ9xLNFfOimr91SsjfD1YeMQ2BEajQCfd1YQ cxtlOekog5s51wO9VgFGrWg= =ZmpA -----END PGP SIGNATURE----- --nextPart2800058.kr7hu27l8v--
I would expect so. I've worked with a USB chip with a microcontroller in it with like 1K words of program memory. An ethernet chip would need more program memory, but surely it exists. If not, we should consider designing one. :) _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Well, are we still thinking about having a 1000Mbit network, or does 100Mbit offer enough bandwidth? If 100Mbit is enough, then I think that we could probably just use http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dD... the ENC28J60 is a 10/100 Ethernet PHY with an SPI interface. That could easily just attach to an FPGA, tiny micro, or anything else we want, because it contains built in buffers. In fact, we could have the "PCI" FPGA that is no longer needed (in this design. Correct?) do DSP decoding and SPI interface, and it talks to the big FPGA for video processing. Or just attach it to the big FPGA directly... nick _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
That URL says it is 10BASE-T which is 10 Mbps, not 100. Unfortunately, 10 Mbps is not fast enough. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
What´s inside a printer on a network ? I suppose that there´s a board, but is there a CPU upon it or a chip _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
In this case (OpenGL accelerator), this would not really be SMP but rather a +/- SIMD system which could have some local data memory. Yes, a SIMD system has dispatch issues (some systems have a dispatch CPU) but this is not as complicated as SMP. With simpler graphics systems, this is simple, if you have 4 processors, you give each of them 1/4 of the screen. OpenGL isn't that simple. One of the reasons that SMP systems don't scale proportionately is that the processors compete for memory access. It should be noted that this is also the reason that faster clock speeds don't scale proportionately -- memory access becomes the limiting factor. -- JRT _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Intel CPUs has a traditional Front Side Bus (FSB). This means a single shared bus between chipset, memory and cpu(s). In other words you have two problems; several components compete for bandwidth and noise. Recent example: on the Xeon line of cpus they could only do 533Mhz instead of 800Mhz like the P4 could do because of the reduced signal quality due to having another cpu on the bus. This of couse reduced the total FSB bandwidth while doubling the theoretical computation rate. In other words, the already memory/io starved cpu got even worse when using two cpus. If using 4-8 cpus this problem gets really critical since the FSB is still constant at 533Mhz. This is to some extent patched over by increasing cache sizes, something Intel has done to a great extent lately. AMD has solved this problem excellently. In a single-cpu system the cpu has 1 or 2 integrated memory controllers plus a separate Hyper Transport (HT) connection to the chipset. This makes sure that chipset and memory traffic never has to compete for bandwidth, and also the latency for the cpu to request something from memory is greatly reduced. In 4-cpu systems each cpu has 3 HT connections plus 2 memory channels each. Thus you have 8 memory channels, and this provides a huge max memory bandwidth. One of the cpus use one HT connection to connect to the chipset, the other two are used to connect to cpu 2 and 4. Cpu 2 uses its HTs connected to cpus: 1,3,4 Cpu 3 uses its HTs connected to cpus: 2,4 Cpu 4 uses its HTs connected to cpus: 1,2,3 As you can see cpus 1 and 3 have no direct connection and has to relay through cpu 2 or 4 (chooses the one with least load). This really has no big impact on performance since the HT links are more than fast enough to handle the traffic. This means that communication between cpus, from any cpu to any memory chip, from any cpu to chipset is a lot more complicated than just using a common FSB. But this is also regarded as a _very_ good solution to the problem since ...
Nope, looks like Intel is sticking with the bus for now, at least in their new Woodcrest chips. For a performance boost they've gone a with a dual bus design (one per core) and sped it up considerably. Doesn't seem most server workloads are memory limited tho. Wil _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
My server workloads most certainly are memory limited, but that is mostly image analysis and such. This means several hundred megs of bitmaps in memory that need to be compared and then new ones created with the data from the analysis. At work we have ~150 Intel servers (P4 and up only) and about 30 AMD servers. All new ones being ordered are AMD. ~80% is servers from Supermicro. What we see is a _HUGE_ boost in database performance. Also mailgateways (spam/antivirus scanning) gets a very nice boost. We havent noticed any difference for webhosting servers. -HK _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Opterons have long since had a performance advantage over the netburst architecture. While memory bandwidth plays a part in that, a lot of that can be contributed to other factors as well such as the latency advantage of the on die controller and shorter pipeline, etc. Friend on mine works on a render farm for a movie studio. They did some side by side comparisons of AMD vs. the new Intel chips & the Intel ones showed a solid performance boost. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
You mean they no longer have? I don't agree with that. Atleast not when talking about the chips commonly available for a reasonable price today. But I do agree that the Opterons are getting dated. The AM2 opterons are better in some respects, but from what I've heard there is more to come in later revisions. Reversed-HT (HyperThreading) for example is one thing I look forward to testing. Instead of Intel's HT where one cpu looks like two, amds dual-core cpus can look like one cpu to the process. So programs/games that are single-threaded or just not multithreaded good enough can benefit since several cores on the same cpu can cooperate on the same tasks. Whether this will have a great impact I don't know, but I think it'll have a bigger impact than HT did. HT was good for when a single-threaded process used 100% cpu; you could still do other things without major lag. Reverse HT should benefit regular office users more than servers Completely different design than the P4 went for, unfortunately for Intel they didn't foresee the fact that they could not go past 4Ghz. I have not tried the new Intel chips, but surely they should be a lot better. Intel has had a lot of foul-ups now so it's about time they deliver something that has a good design from the start. Btw, Intel makes the best Network cards. Unless you need myrinet or something like that, but that costs a great deal more too. -HK _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Another reason to like X-Terminals. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I have been wondering where should this be documented, as I cant find it on the wiki: http://wiki.duskglow.com/tiki-index.php?page=FeatureList oga featurelist? http://wiki.duskglow.com/tiki-index.php?page=OGD1 odg1 page or perhaps the planning page http://wiki.duskglow.com/tiki-index.php?page=Planning any preference? jb _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
I think the feature list. OGD1 is a separate product. Planning is for what needs to be done. The feature list can include planned features for OGA-based chips and boards. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
In Linux and BSD, _nothing_ ever goes away. Part of the mission is to run on the installed base. A lot of that is PCI. Some of it is ISA. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Not true, unfortunately, Suse Linux dropped support for the Alpha awhile back. Surely you aren't suggesting building an ISA graphics card? _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
Suse and FreeBSD are not the whole of "Linux and BSD", there's plenty of your core market that is running older hardware, and there are plenty Hey, I've still got some ISA boards lying around here. ;-) Seriously, though, people using older hardware are likely to be using vintage video cards too -- and most of those are sufficiently "open" to not present any problem (they're framebuffer cards and the like). Anybody who's going to pop for a $200+ video card is going to be willing to buy a $50 motherboard if they need to upgrade. I believe all of my systems are currently AGP for video, though. And AMD CPUs (I have been distrustful of Intel ever since the P60 incident, and the digital snitch CPUs didn't make me happy either). Cheers, Terry -- Terry Hancock (hancock@AnansiSpaceworks.com) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
So? Going away is going away. If you need feature Foo on an Alpha and only FreeBSD (or Suse) has I have older hardware. I have hardware that Linux will never support. I have hardware that not even Net "Would you like toast with that?" BSD I'm not familiar with the "P60" or "digital snitch" problems. Intel has way too many bugs for my poor little brain to keep track of. I've known since ~1979 that Intel didn't care about its customers and that's all I need to know. Rest assured that no Intel CPUs are converting electricity into heat and incorrect answers here. Hmmmm, this has drifted a bit far from the OGP. I'd better cool it before I have to stay after school and write an APL to Verilog translator. _______________________________________________ Open-graphics mailing list Open-graphics@duskglow.com http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
