| | Logging Started : Fri Jun 05 18:40:21 EDT 1998 |
| | anoq (anoq@msx-18-1-3.1033.cybercity.dk) has joined channel #berlin |
| | graydon greets anoq |
|
anoq:
|
hello!
|
|
anoq:
|
Are we the only ones? Has the meething started
|
|
anoq:
|
?
|
|
graydon:
|
heh. I just left work and came home to do the meeting from here. Brent and I are here.. netgod is I think lurking but here ;)
|
|
graydon:
|
meeting hasn't started exactly, but feel free to talk
|
|
anoq:
|
Hi Brent!
|
|
anoq:
|
Well... aren't we almost 2 hours late?
|
|
graydon:
|
anoq: I'm not sure. It's possible this is all we're going to get. mentalguy was here an hour ago, and had to go.
|
|
anoq:
|
I just got home from a birthday-party, and thought that I'd missed the whole thing... ;)
|
|
graydon:
|
today is my birthday -- I turned 21
|
| | anoq congratulates Graydon :) |
|
anoq:
|
Happy birthsday to you,... happy - ohh sorry :)
|
| | graydon is having a pretty good day, but it would be better if I calculated times properly :( |
|
anoq:
|
It's fine with me :)
|
|
bfulgham:
|
Hey guys, I wasn't paying attention...
|
| | graydon has set the topic: "Berlin meet -- Brent is back to life" |
| | graydon has set the topic: Berlin meet -- Brent is back to life |
|
anoq:
|
Well...
|
|
graydon:
|
anyone have a loot at the lifecycle implementation I did? I have yet to test it.
|
|
graydon:
|
I've been too absorbed in learning openGL.
|
|
bfulgham:
|
Happy birthday Graydon! I think you're only 1 hour late, aren't you? I had down 6pm EST, which is 3PM out here in California.
|
|
graydon:
|
I think the problem is that I don't know whether I'm in EST or EDT, so I just pick one randomly, usually wrong.
|
|
anoq:
|
Graydon: No, I haven't had the time :(
|
|
bfulgham:
|
I haven't looked at the lifecycle stuff. I basically got berlin to compile, then got hung up when trying to get it to run in straight kgi when someone (*ahem*) "enhanced" the makefiles...
|
|
graydon:
|
It's a new parent for cloneable that makes us more COSS compliant.
|
|
graydon:
|
I'm still a little frustrated that omni's lifecycle is nonstandard, but I can at least see why they did it.
|
|
graydon:
|
I got TAO compiling, but there's *zero* documentation, so I can't exactly tell how to make it work.
|
|
anoq:
|
I haven't even read the lifecycle docs yet... :(
|
|
graydon:
|
anoq: It's really very simple: create_object(key), delete(), move(), copy(). .. thats it
|
|
graydon:
|
anoq: but I wrote one which does demand-loading from shared object files!
|
| | graydon grins mischeviously |
|
anoq:
|
Graydon: OK! :) What is key?
|
|
graydon:
|
key is a typedef for COS_naming::Name .. it's one of those sequence structures. Basically a fully qualified path name.
|
|
anoq:
|
Path for a lib-file?
|
|
graydon:
|
Anything-path. Naming is entirely abstract. I think we should define them as symbolic constants in a helper class.
|
|
graydon:
|
Rogue strings in your code are bad -- just put up with a lot of that at work and it's not pretty.
|
|
anoq:
|
Yearh... or a registrar entry?
|
|
graydon:
|
anoq: yeah, that'd be ideal.
|
|
graydon:
|
Ok, out of curiosity, raise yet hand if you've had a look at OpenGL yet?
|
|
bfulgham:
|
Helper class: A "name safe" that you access to get a particular key? e.g., key = myNameSafe.getkey(foo)?
|
|
anoq:
|
Throw hand();
|
|
anoq:
|
Oopps... it raises a hand in C++ anyway :)
|
| | bfulgham Brent looks sheepishly at the floor. He obviously has only visited some OpenGL websites and admired the graphics. |
|
graydon:
|
bfulgham: even Namesafe::SomeSymbolicName is better than nothing. At least your typos will be caught by the compiler.
|
|
bfulgham:
|
Anoq: Isn't it a hand exception?
|
|
anoq:
|
brent: yes...
|
|
graydon:
|
I think it's "throw new hand()" in C++.. anyway you're all a bunch of geeks ;)
|
| | graydon chuckles. I was just checking! |
|
anoq:
|
Yup! :)
|
|
anoq:
|
graydon: you forgot ;
|
|
anoq:
|
he he!...
|
| | graydon is a C++ loser. You can throw rotten vegetables at me now. |
|
anoq:
|
How do I do that in IRC?
|
|
graydon:
|
"use /me does something"
|
|
graydon:
|
oops
|
|
anoq:
|
BTW: Graydon: I agree with the compiler typo-stuff above...
|
|
graydon:
|
use "/me does something"
|
| | anoq out of rotten vegetables ;) |
|
graydon:
|
Ok, here was my original agenda:
|
|
graydon:
|
* rundown of linux expo
|
|
graydon:
|
* discussion of openGL
|
|
graydon:
|
* TAO evaluation
|
|
graydon:
|
* new lifecycle implementation
|
|
graydon:
|
* other items you are interested in
|
|
graydon:
|
|
|
bfulgham:
|
Yes. I agree with the namespace stuff above -- although using NAMESAFE::yadayada can get hard to read after awhile. But, at least it's specific about where you're pulling information (no namespace collisions or accidental polymorphism)
|
|
graydon:
|
bfulgham: you have to use "inner classes" in egcs right now cause it's missing namespace support, or so I am told. Anyway it's something worth considering when we start handing out string-names for things.
|
|
graydon:
|
shall we assume this is all the people we'll get and then be pleasantly surprised if more show up?
|
|
anoq:
|
I guess so
|
|
bfulgham:
|
graydon: Fine with me.
|
| | graydon has set the topic: "Berlin meet -- Linux Expo" |
| | graydon has set the topic: Berlin meet -- Linux Expo |
|
graydon:
|
I guess I was the only one there, right?
|
|
bfulgham:
|
Yes,
|
|
anoq:
|
I weren't there at least
|
|
bfulgham:
|
I mean yes.
|
|
graydon:
|
I met up with some people who were on the berlin list, and were interested in having a BOF
|
|
anoq:
|
BOF?
|
|
graydon:
|
"Birds of a Feather" -- informal meeting
|
|
anoq:
|
ok
|
|
graydon:
|
We had one, and as I said about a dozen people showed and asked lots of good questions
|
|
graydon:
|
Mostly about status and compatibility -- GNOME was showing off GTK+ a lot and it had everyone interested in GTK compatibility
|
|
graydon:
|
Then one guy whose name I did not get started to talk to me about OpenGL and how it already handles paths etc.
|
|
graydon:
|
I went to see Bruce speak on behalf of pixar, and his big point was that without good 3d apps and good imaging, linux & X were goung to have a hard time competing against NT workstations.
|
|
graydon:
|
Linux would essentialy be relegated to the position of "render farm"
|
|
graydon:
|
So I was very encouraged in my quest to learn GL
|
|
graydon:
|
I went and talked to bruce about it, and he seemed excited by the prospect, asked me when we'd be ready to demo
|
|
graydon:
|
I said end of summer
|
| | graydon grins |
| | bfulgham Faints |
|
graydon:
|
DEMO.. not ready. I was clear on that. Just something that works a little. I don't think that's unreasonable.
|
| | bfulgham Comes to... |
|
anoq:
|
We've got Mesa-GGI - right?
|
|
graydon:
|
I talked a lot with jmcc, steffen and andreas about getting Mesa-GGI working. Steffen seemed a little bummed out but the other two were still very enthusiastic
|
|
graydon:
|
I am running Mesa-GGI right now in an X window.
|
|
graydon:
|
So Yeah, it's not a crazy timeline
|
|
anoq:
|
Cool!
|
|
anoq:
|
Wrapping it in IDL shouldn't be too hard...
|
|
graydon:
|
I'm experiementing with getting frame rate up by nocking out stages of the pipeline ;)
|
|
graydon:
|
Agreed.
|
|
anoq:
|
How about optimize?
|
|
graydon:
|
I mentionned real alpha channels and polygons to raster and he started foaming at the mouth ;)
|
|
graydon:
|
anoq: that's the real trick. I haven't looked long enough at mesa to know how easily it can be broken up. I intended to last night, but got dragged out for birthday party.
|
|
graydon:
|
It's critical that it call into hardware as soon as possible though.
|
|
anoq:
|
yes
|
|
graydon:
|
Now, OpenGL has this one problem, which is that it's decidedly unfriendly to OOP. It's more like a single enormous state machine.
|
|
anoq:
|
BTW: Mesa already does phong and gauraud shading right?
|
|
graydon:
|
anoq: yeah
|
|
graydon:
|
anoq: it basically does anything you can think of, if you turn the feature on.
|
|
anoq:
|
I mean, is it implemented yet?
|
|
anoq:
|
Does it work?
|
|
graydon:
|
anoq: I believe so, yes. I run it in flat mode for testing but I think it's got a full set of shaders.
|
|
anoq:
|
cool!
|
|
graydon:
|
so I've been looking around for an OO toolkit to manage state encapsulation and whatnot, and to be honest i haven't found too much yet. There's one called "Apprentice" which is identical to open Inventor. Only problem is that the author has put it under "academic and noncommercial only" license. I'm contacting him to ask for a true GPL/LGPL release.
|
|
graydon:
|
If the author is amenable, that would be ideal.
|
|
anoq:
|
Is it necessary with an oo-toolkit for this?
|
|
bfulgham:
|
I'm surprised that such a toolkit doesn't already exist. My OpenGL knowledge is lacking -- but does GLUT do any of that?
|
|
graydon:
|
anoq: not entirely. It's just that if we export openGL API directly through corba, it's 1 big (BIG!) interface and if a client mucks with it they are mucking with the entire display environment. That's no good. So we need to encapsulate in some way. Might be as minimal as providing one "context" object per app, although that's a little crude.
|
|
graydon:
|
GLUT seems to do some of it, yeah. I haven't gone too far in depth with GLUT yet, but I suspect it'll help. I've found some funny stuff actually, hang on.
|
|
graydon:
|
http://users.deltanet.com/~powerg/Apprentice/
|
|
graydon:
|
That's the apprentice site
|
|
graydon:
|
If you want proof that you can draw GUIs in OpenGL, look at http://reality.sgi.com/opengl/tips/mui/mui.html
|
|
anoq:
|
Isn't SGI's GUI entirely OpenGL?
|
|
anoq:
|
At least SoftImage's GUI is, but OK that's ugly too...
|
|
graydon:
|
anoq: possibly, I don't know. I know moonlight creator is 100% openGL.
|
|
graydon:
|
I mean, they might be a little ugly, but that's no cause for alarm.
|
|
graydon:
|
nothing mandates "must look ugly" in openGL. God, I hope not!
|
|
anoq:
|
Those examples on that site looks like IRIX's GUI...
|
|
anoq:
|
I don't like it too much, but I think anything can be done with OpenGL...
|
|
anoq:
|
(I don't like = IRIX GUI)
|
|
bfulgham:
|
graydon: OpenGL != ugly. Usually, programmer.artistic == BAD is usually the problem.
|
|
anoq:
|
brent: Yes!
|
|
graydon:
|
yeah, agreed. We have a nice set of people with taste in the linux community so it should be no problem.
|
|
anoq:
|
And with pluggable L&F...
|
|
bfulgham:
|
Frankly, it looks like you can make all kinds of widgets 'n stuff, so it's just a matter of someone with good skills to draw 'em up.
|
|
anoq:
|
Well, OpenGL is just drawing commands :)
|
|
bfulgham:
|
Anoq: Right. We need a baseline "standard" mode, then user definable. Think Java's Swing pluggable Look'n'feel.
|
|
graydon:
|
anoq: it's drawing *and* pixel management. You can use pixmaps if you like.
|
|
anoq:
|
Yes, I know...
|
|
anoq:
|
But that's drawing too :)
|
|
graydon:
|
cool, OK, so I guess the onus is on me now to make a groovy server which compiles and shows a window. Sigh..
|
|
graydon:
|
anoq: yeah, but you don't need a vector for every pixel, if you know what I mean. You can bulk import data at screen res if that's your style
|
|
anoq:
|
Yearh...
|
|
anoq:
|
So we all love OpenGL?
|
| | graydon nods |
|
graydon:
|
OK, next issue I guess is TAO
|
| | graydon has set the topic: "Berlin meet -- TAO" |
| | graydon has set the topic: Berlin meet -- TAO |
|
graydon:
|
Tao is "The ACE Orb"
|
|
graydon:
|
ACE is "Adaptive Communications Environment"
|
|
graydon:
|
Tao is a nice fast ORB with no documentation.
|
|
graydon:
|
I would like to maintain it as a possibility for future work.
|
|
graydon:
|
It allows realtime on communication channels which support it
|
|
graydon:
|
it has event service as well as some sort of lifecycle service. I don't know how either works, because, you guessed it, no documentation.
|
|
anoq:
|
I think it sounds very attractive too...
|
|
anoq:
|
for future work that is...
|
|
graydon:
|
anoq: agreed. It was too much hassle this time around to stall all work and switch. When we have more hands, it will be less work.
|
| | graydon has set the topic: "Berlin meet -- Lifecycle" |
| | graydon has set the topic: Berlin meet -- Lifecycle |
|
anoq:
|
Yearh... getting something up and running would be goo...
|
|
anoq:
|
d
|
|
graydon:
|
Ok, I have implemented a new GenericFactory
|
|
graydon:
|
GenericFactory is a thing which is found by a factoryFinder.
|
|
graydon:
|
I still have not implemented a factoryFinder
|
|
graydon:
|
Client asks factoryFinder to find a factory and produce an object matching a key and some criteria
|
|
graydon:
|
factoryFinder finds our genericFactory
|
|
anoq:
|
how many different factories can it find?
|
|
graydon:
|
our GenericFactory looks into the /prototypes name context for the key. If there's an object there, it clones it and returns the clone. If there's no object there, it tries to load one from disk.
|
|
graydon:
|
anoq: as many as you like. factoryFinder is abstract. Right now I intend for it to find the factory on the current display server.
|
|
graydon:
|
If it can't load from disk, an exception propagates back to the client.
|
|
graydon:
|
Right now the list of key names is produced during startup by the display server scanning .so files in subdirectories.
|
|
graydon:
|
That has to be fleshed out a little, but that's the general idea.
|
|
graydon:
|
questions?
|
|
anoq:
|
Sounds ok
|
|
bfulgham:
|
What kind of things are considered "Factories"? (Lack of ORB knowledge)
|
|
graydon:
|
factories are objects which satisfy the CORBA::Object_ptr create_object(key, criteria) method.
|
|
graydon:
|
The idea being that they encapsulate a method for making objects of some sort.
|
|
graydon:
|
the client does not need to know how the objects are produced.
|
|
anoq:
|
Like an Objective-C factory method?
|
|
graydon:
|
They may be coming off disk from a persistent OODBMS, etc..
|
|
graydon:
|
Using the "new" operator is no good because the clients all need to be updated when you alter implementation.
|
|
bfulgham:
|
The factory then returns the object...I see. This is very OO (which is IMHO a good thing), but what about Raster et. all who want to use C?
|
|
graydon:
|
Heh
|
|
graydon:
|
bfulgham: raster is using GTK right now. GTK looks *exactly* like the CORBA C binding.
|
|
graydon:
|
GTK is fully OO, it just happens to be C-based.
|
|
graydon:
|
They won't notice any difference imho.
|
|
bfulgham:
|
Great.
|
|
anoq:
|
Still sounds good...
|
|
graydon:
|
As for a C orb, that's an admitted problem that everyone who is C-only raised.
|
|
graydon:
|
I have no answer. There's ILU, which is not perfectly licensed, and miguel said someone in GNOME is working on "ORBit", a C ORB.
|
|
bfulgham:
|
I've noticed the ORBit discussion, but it's nowhere near being ready to use. Besides -- I'd rather use an off-the-shelf item that someone else will have to maintain ;)
|
|
anoq:
|
Isn't it just a matter of writing a new language-binding for omniORB, TAO or similar?
|
|
graydon:
|
anoq: yes. That's just not a small task. Nobody has one yet.
|
|
graydon:
|
anoq: but it's within the realm of reality. There's a custom-built perl ORB ;)
|
|
graydon:
|
Don't know if it works well yet.
|
|
anoq:
|
I'm more interested in ML... :)
|
|
graydon:
|
anoq: you and me both
|
|
anoq:
|
OpenGL in ML... YES!
|
|
bfulgham:
|
How tied are we to a particular ORB? I mean, if someone had Mico or similar on their system could they use Berlin stuff? Would they have to recompile everything to work with it? I don't know too much about how this works...
|
|
graydon:
|
anoq: CORBA's type-parameterization semantics isn't strong enough to work for ML-> IDL, but you could do IDL->ML ok.
|
|
bfulgham:
|
ML =? Machine Language? Markup Language? M?
|
|
graydon:
|
ML == Meta Language
|
|
anoq:
|
Meta-language
|
|
anoq:
|
What would ML->IDL be good for?
|
|
anoq:
|
Brent: recompile? yes, rewrite? no
|
|
graydon:
|
anoq: obviously you haven't seen products which scan java source code and automatically generate IDL, compile it, and link against the compiled stubs and skeletons yet. They're cool.
|
|
anoq:
|
No rewrite if the standards are followed
|
|
graydon:
|
anoq: some rewriting will be necessary.
|
|
anoq:
|
graydon: sounds cool...
|
|
graydon:
|
anoq: the BOA interface is nonstandard
|
|
anoq:
|
But I don't think I'll need it ;)
|
|
graydon:
|
anoq: but nothing too big. Basically not much more than a perl script could accomplish in 10 minutes.
|
|
bfulgham:
|
I'm thinking of the Gnome stuff, which is severly tied to Mico. I've played with hacking their makefiles somewhat to work with OmniORB, but I haven't had time to really spend messing with it.
|
|
anoq:
|
graydon: 10 minutes on a pentium? ;)
|
|
graydon:
|
That's as far as actually *running* berlin on mico. You can use mico to *talk* to berlin as it is now.
|
|
graydon:
|
9 minutes of writing correct code, 58 seconds to go to the bathroom, 2 seconds to rewrite all of our C++
|
|
bfulgham:
|
Graydon: So I could have a Mico-based server somewhere that could speak to my OmniORB Berlin platform and serve up hot widget factories as requested, as long as the widget factory was mico-ish on the mico-server?
|
|
graydon:
|
at least, you *should* be able to use mico to talk to berlin now. Not sure it works.
|
|
graydon:
|
yes
|
|
anoq:
|
it would possibly work in the future
|
|
anoq:
|
bugfixes etc...
|
|
graydon:
|
the ORB implementation is *supposed* to be invisible to apps. Like your TCP vendor being invisible. Not always the case though..
|
|
graydon:
|
lifecycle defines interfaces for moving objects between ORBs while they are running.
|
|
graydon:
|
This is all blue-sky though. I should get to work. Any more things worth discussing?
|
|
anoq:
|
I have noting really...
|
|
graydon:
|
david just mailed saying he wants to show up, so I'll stay here till he arrives.
|
|
graydon:
|
I'm gonna start working on more GL code in background though.
|
| | Silk (billl@piccolo-39.synapse.net) has joined channel #berlin |
|
bfulgham:
|
Graydon: Let's talk ggi for a second.
|
|
bfulgham:
|
(Anoq too)
|
|
anoq:
|
ok
|
|
bfulgham:
|
I've been mucking around with their stuff, and as you know they have re-opened CVS (or will this weekend)
|
|
graydon:
|
yes, I'm very happy about that
|
|
bfulgham:
|
Anyway, I think they're getting fairly close to a point where we should start trying to run Berlin on top of KGI (kernel only, no X)
|
|
bfulgham:
|
I haven't gotten this to work yet, myself, but got close.
|
|
Silk:
|
(hi)
|
|
graydon:
|
I agree. I spent yesterday afternoon trying, and it didn't *quite* work.
|
|
anoq:
|
Who is Silk?
|
|
bfulgham:
|
I also want to modify the entry point on Berlin so it will take parameters to set mode.
|
|
bfulgham:
|
Silk: Greetings!
|
|
Silk:
|
anoq: just an interested layman
|
|
graydon:
|
bfulgham: yeah. Yeah a set of command-line params would be good.
|
|
anoq:
|
Silk: Cool! Hi!
|
|
graydon:
|
bfulgham: the main() is really dopey at the moment.
|
|
bfulgham:
|
That should be easy. I may do it this evening, but I'm going on vacation next week (leaving crack of dawn tomorrow) so I'll have to use a pad of paper for the time being...
|
|
graydon:
|
You may have notices, brent, that I've charged you with the ungodly task of getting a match between GGI branches and the kernel.
|
|
graydon:
|
heh
|
|
bfulgham:
|
Heh heh. I wish I knew what that meant!
|
|
bfulgham:
|
Just kidding.
|
|
graydon:
|
yeah, it's a pain. Moving targets!
|
|
graydon:
|
I'm sure it'll settle after the GGI meeting tonight. Anyone there right now?
|
|
bfulgham:
|
I still think EvStack (now ggi Console) is the way to go. The drivers are being ported now (to EvStack) and the library should follow soon.
|
|
bfulgham:
|
Oops -- I don't know. I haven't visited.
|
|
bfulgham:
|
Anyway, degas will look a lot like dali to us. It's the internals that are changing.
|
|
graydon:
|
yeah. jmcc talked about evstack in very good tones at Linux Expo. Especially encouraging that they have found that by using /dev/event they can move almost all the code out of the kernel. Makes the kernel developers much happier.
|
|
bfulgham:
|
I also want to help with Mesa on ggi. (*Must Learn OpenGL*)
|
|
bfulgham:
|
Yep. We need to get a critical mass so that Linus et. al. will be open to pulling stuff into the kernel. The less the better.
|
|
anoq:
|
Just a note: Do we still need NURBS with Mesa?
|
|
graydon:
|
The proceedings -- damn, I wish steffen had posted them. The proceedings of his talk were cool. They talked a lot about hot to accelerate drawing using a curcular buffer of commands.
|
|
graydon:
|
anoq: mesa has nurbs
|
|
bfulgham:
|
I've gotten a few mails that postulate that he doesn't want to add more to the kernel for fear that he will be left holding the "maintenance bag".
|
|
bfulgham:
|
(oops. He = Linus)
|
|
graydon:
|
anoq: mesaGLU (utility library) is missing NURBS trimming. You can work on that if you know NURBS :)
|
|
graydon:
|
bfulgham: I believe you're right on that one. He's very bogged down.
|
|
anoq:
|
I haven't read NURBS specs detailed yet, but I think I'm going to soon...
|
|
graydon:
|
brb -- washroom break
|
|
Silk:
|
if anyone's interested in learning opengl, I'd heartily recommend "OpenGL Programming Guide: 2nd Ed" (the "Red Book"). It's very good.
|
|
bfulgham:
|
Silk: Do you know if there's much difference between 1.0 and 1.1?
|
|
anoq:
|
I have got OpenGL reference manual. It's OK too, but it's just hard specs... :)
|
|
Silk:
|
bfulgham: afaik texture mapping wasn't properly implemented in 1.0.
|
|
graydon:
|
I bought the openGL programming guide this monday. Have been devouring it al week.
|
|
Silk:
|
Mesa 3.0 will cover the 1.2 spec though, so no worries
|
|
bfulgham:
|
Not worth it then. All of the 1.0's books are cheaper (on sale?) heh
|
|
bfulgham:
|
I'll get the full 1.1
|
|
graydon:
|
Silk: have you looked inside mesa?
|
|
Silk:
|
graydon: A bit.. I had a look at the texture mapping and camera code
|
|
graydon:
|
Silk: is it cleanly modularized?
|
|
Silk:
|
graydon: not sure what you mean
|
|
graydon:
|
Silk: or a big hairy mess? -- would it be easy to break off small portions and move them to hardware accel?
|
|
Silk:
|
graydon: oh.. well, I think Brian has a driver spec which allows you to replace the triangle drawers with your own implementations
|
|
Silk:
|
that's how the mesa-glide driver works, I think
|
|
graydon:
|
excellent. I should start talking to him actually.
|
|
graydon:
|
silk: that runs setuid root right?
|
|
Silk:
|
graydon: yeah, glide is setuid.. though I hear the next version will have a /dev/3dfx which eliminates that need
|
|
graydon:
|
cool
|
| | graydon is reading the mesa sources at the moment, so will be slightly unresponsive |
|
bfulgham:
|
I know Mesa's been moving toward hardware acceleration. The Win32 S3/Virge driver already uses some, but not Linux *yet*.
|
|
Silk:
|
bfulgham: the 3d hardware market is too competitive right now.. I don't think we can count on robust opensource opengl drivers for a while yet, unless something changes
|
|
Silk:
|
which is why it's (imo) important to get mesa running fast in software mode
|
|
graydon:
|
I dunno ... http://www.3dfx.com/software/download_openglbeta2.html
|
|
bfulgham:
|
Why? Because of the moving target hardware-wise, or are the mfrs. not wanting to release specifications?
|
|
graydon:
|
I agree we cannot *count* on hw accel, but we absolutely must *use* it when it's present.
|
|
Silk:
|
bfulgham: manufacturers not wanting to release specifications, mainly
|
|
anoq:
|
Silk: And that _is_ possible! :) I use LightWave with OpenGL on my NT
|
|
anoq:
|
machine without 3D-hardware, and it's pretty OK fast...
|
|
bfulgham:
|
We might have to hand-code bottlenecks...
|
|
Silk:
|
anoq: try turning on texture mapping, and watch the speed grind way down =)
|
|
anoq:
|
It doesn't do textures... :(
|
|
bfulgham:
|
Silk: The Mesa page indicates that someone at S3 is doing the port, but who knows...
|
|
graydon:
|
so long as the design permits it, I suspect handcoding 3d routines in assembler will be a source of much joy and pride amongst young hackers.
|
|
anoq:
|
It's only LightWave5.0 :(
|
|
bfulgham:
|
Everyone: What about pentium MMX routines and the new AMD K6-2 3D routines (drool...) Compiler issue? If we have to make stuff run fast in SW it might be useful. I dunno. Too hard to keep things portable.
|
|
Silk:
|
bfulgham: SGI OpenGL for Windows uses MMX instructions, which makes blending/tmapping several times faster, which is still pretty slow
|
|
graydon:
|
Oh, those are good instructions. I get sick of people bellyaching about them. MMX et all are very useful.
|
|
anoq:
|
graydon: Imagine the whole world of geeks hacking the OpenGL-engine... It should become the fastest software OpenGL on the planet :)
|
|
graydon:
|
anoq: if they know what they're doing, yeah.
|
|
anoq:
|
agree...
|
|
bfulgham:
|
L00zer accidently fries the CPU by hitting the same register over and over...
|
|
anoq:
|
heh...
|
|
anoq:
|
Not very attractive I guess...
|
|
graydon:
|
mmm.
|
|
graydon:
|
tasty
|
|
graydon:
|
The assembler is quite cleanly separated in mesa
|
|
bfulgham:
|
Graydon: Then it's probably possible to create CPU-specific accelleration routines to use MMX and others.
|
|
Silk:
|
bfulgham: they already have started
|
|
Silk:
|
the latest beta of Mesa includes some MMX code for blending
|
|
bfulgham:
|
Silk: Fantastic!
|
| | bfulgham Brent decides it's finally time to update his old 75Mhz Pentium... |
|
anoq:
|
brent: Is it fast? ;)
|
|
anoq:
|
your new machine that is...
|
|
Silk:
|
graydon: this is probably going to sound naive, but how exactly are you proposing to draw a 2d-Xwindowish screen with OpenGL? texture mapping? gldrawpixels?
|
|
anoq:
|
Silk: drawline, drawpolygon etc..?
|
|
graydon:
|
silk: some of both. I'll be honest and say I don't know the relative merits well enough.
|
|
graydon:
|
silk: I expect to use GL to do Z buffering (so we don't need to keep a complex, shaped window stack) and then just paint on the polygons as fast as I can.
|
|
anoq:
|
Ooohhh shit... SoftImage on NT has an ugly OpenGL GUI, and it is _really_ slow...
|
|
graydon:
|
I think hardware textures will give good speed for text
|
|
anoq:
|
Perhaps it is not suited for GUIs?
|
| | mass- (davewait@fn3.freenet.tlh.fl.us) has joined channel #berlin |
|
graydon:
|
hey dave
|
|
mass-:
|
haha I knew I'd be late =)
|
|
mass-:
|
hello
|
|
graydon:
|
anoq: where are you seeing this?
|
|
bfulgham:
|
Anoq: Not fast, but not too bad. I'm running on a 75Mhz. bus speed, which helps.
|
|
bfulgham:
|
Dave --hello.
|
|
Silk:
|
anoq: well, as it stands, I personally don't think it is.. but it may be, eventually
|
|
mass-:
|
hello all =)
|
|
graydon:
|
silk: do you have any suggestions?
|
|
anoq:
|
On a 166Mhz pentium with Matrox millenium, 4MB
|
|
anoq:
|
96MB RAM
|
|
mass-:
|
so have I missed anything in the first hour or so?
|
|
anoq:
|
hello david!
|
|
Silk:
|
graydon: optimise the pipeline for the 2dish needs of berlin
|
|
graydon:
|
dave: a little, mostly discussing OpenGL and various ORBish things.
|
|
mass-:
|
ahh
|
|
Silk:
|
right now, Mesa is more of a reference implementation for OpenGL
|
|
graydon:
|
silk: that's the intent. I hope it's possible.
|
|
mass-:
|
I'm at work doing OpengL-ish stuff right now
|
|
graydon:
|
dave: cool. I assume you know it better than I do.
|
|
Silk:
|
ie: so people can run their opengl programs on X-Windows
|
|
graydon:
|
silk: yeah, I got the feeling mesa deveopers see it as an "add on" to a windowing system..
|
|
Silk:
|
mass-: Do you know anything about the OpenGL idea of fast-paths?
|
|
mass-:
|
I'm learning =)
|
|
mass-:
|
Right now I'm trying to find a way to convert triangles to triangle strips, it'll give me at least a 50% speed boost
|
|
Silk:
|
graydon: well, afaik that's how it was originally conceived.. by silicon graphics to sell lots of x-windows boxs
|
|
Silk:
|
mass-: what kinda model are you trying to convert into strips?
|
|
mass-:
|
a tooth, we are working on a dental visualization thing
|
|
mass-:
|
the model has like 30k+ triangles, and we need more dynamic feedback than 1.5 seconds per frame =)
|
|
anoq:
|
mass: Try an SGI octane with Maya... :)
|
| | Fatal (pauld@titan.hutch.com.au) has joined channel #berlin |
|
mass-:
|
haha
|
|
graydon:
|
hey paul
|
|
mass-:
|
its for a commercial product though, on sonsumer systems
|
|
Fatal:
|
hey there
|
|
mass-:
|
consumer
|
|
mass-:
|
I can't tell them all to buy Onyx2's now, can I?
|
|
bfulgham:
|
Is there any lack of functionality in GGI-Mesa vs. x-windows mesa?
|
|
Fatal:
|
hows the meeting coming along?
|
|
anoq:
|
mass: ohh.... I see...
|
|
bfulgham:
|
Fatal- Hello
|
|
anoq:
|
mass: Seriously, an O2 is quite cheap and quite speedy...
|
|
graydon:
|
bfulgham: there's a lack of acceleration according to jmcc, but that's not surprising.
|
|
Silk:
|
bfulgham: probably.. GGIMesa uses a small api to get graphics onto the screen, x-windows mesa uses glx-emulation
|
|
anoq:
|
mass: but a PC with OpenGL board may still be better...
|
|
graydon:
|
fatal: we're sorta in a free-for-all talk on OpenGL at the moment.
|
|
anoq:
|
hello Fatal!
|
|
mass-:
|
I think that GGI-mesa is the same thing. it just has hooks for using hardware acceleration
|
|
mass-:
|
none of the hooks are used righ tnow, it just does putpixels
|
|
Silk:
|
mass-: individually called putpixels? ouch
|
|
mass-:
|
I honestly don't know
|
|
bfulgham:
|
S3/Virge is only a partial OpenGL implementation, with the rest in hardware. I suspect texture mapping/etc is mising, but don't know. Any recommendations on a bargain-basement OpenGL board?
|
|
graydon:
|
mass: yeah, it pitpixels in strips. There's a macro called, I think, INNER_LOOP or something, that just lays down strips of pixels.
|
|
mass-:
|
since I'm going to be working in OpenGL all summer, I figured I could look at GGI-Mesa too =)
|
|
Silk:
|
bfulgham: 3dfx is pretty much the only supported opengl hardware under linux
|
|
mass-:
|
I'm working 40 hrs/wk and taking 7 hours of summer classes though. There isn't that much freetime
|
|
graydon:
|
bfulgham: I understand 3dfx has some support right now
|
|
mass-:
|
glide
|
|
graydon:
|
bfulgham: permedia and matrox boards have the hardware, but no linux drivers thru GGI yet.
|
|
Silk:
|
bfulgham: supposedly some people are working on rendition v2x00 and permedia support, but if/when they'll be released is anyone's guess
|
|
mass-:
|
and someone wrote a 3dfx wrapper for mesa, it is pretty fast nowadays
|
|
bfulgham:
|
I've seen a Diamond board that's supposed to be an add-on to your existing 2D board. Anyone know if this thing works or is it a problem?
|
|
Fatal:
|
how is all of this mesa stuff going to affect performance/code bloat? seems like we'll be getting bloatier than X :/
|
|
bfulgham:
|
This uses the 3dfx chip, I understand.
|
|
mass-:
|
I'm a know-it-all when it comes to 3d. I haven't had much real-world experience, but I understand the ways things work =)
|
|
graydon:
|
3dfx boards are mostly like that, side-by-side with an existing 2d board. You flip it into 3d mode and it kills your 2d card's video signal.
|
|
graydon:
|
fatal: we have more features than X ;)
|
|
graydon:
|
fatal: but yes, it's a concern.
|
|
mass-:
|
yes. 3dfx's next product, the Banshee line, is integrated 2d/3d, it supports multiple 3d views in windows too. Tre' cool
|
|
mass-:
|
Thats supposed to come out in E3, I'm trying to get an eval though
|
|
mass-:
|
err Q3
|
|
Fatal:
|
seems our goals have shifted quite heavily from the original berlin mission statement... but thats not a bad thing
|
|
graydon:
|
fatal: I weigh it like this: an ORB = 1mb, Mesa = 600k, Our code = ?
|
|
Silk:
|
Fatal: what was that again? "Assembly language is hip!"? =)
|
|
mass-:
|
haha
|
|
Fatal:
|
haha
|
|
Silk:
|
seriously, I think this Mesa stuff could be really cool if it works out properly
|
|
mass-:
|
I think things are facing the right direction, I've just been too busy in the last few months to actually see how things are moving forward =)
|
|
graydon:
|
fatal: my X server = 2.7 megs, + 1.5 megs of X support libraries
|
|
mass-:
|
I am looking forward to getting Redhat 5.1 just because it gives me an excuse to reinstall
|
| | Fatal brought two magazines last week which had corba articles in them so hopefully i'll be in better shape to assist when things reach a higher level |
|
mass-:
|
I know some ActiveX because of work, I still don't know any Corba =P
|
|
anoq:
|
I'm tired.... it's 2:45 am here, and I haven't slept much the last couple of days, so I think I'm leaving now...
|
|
graydon:
|
fatal: I think we're still on target. There was initial shock value to the size of the skeletons and stubs, but if you use a shared library ORB with good modularity the stubs are very small.
|
|
mass-:
|
ahh.. g'night
|
|
graydon:
|
gnight anoq
|
|
Fatal:
|
bye anoq
|
|
graydon:
|
thanks for coming
|
|
anoq:
|
Nighty then!
|
|
anoq:
|
You too - all
|
| | Signoff: anoq (Leaving) |
|
graydon:
|
forgot to tell all the newcomers: today is my birthday so I'm going out for cake soon with my brother ;)
|
|
Fatal:
|
hehe happy bday graydon :)
|
|
graydon:
|
If you got any major burning questions you better get 'em over with now
|
|
Fatal:
|
yes.. wot timescale would u give before we have something 'up on the screen'? 3 months?
|
|
bfulgham:
|
Actually, I've got to run too. See you all later. Graydon: I'm gone next week, so can't attend the Friday GGI/Berlin IRC. Can you log it (if you can attend, that is) so I can read it? Thanks for the great discussion guys.
|
|
Fatal:
|
not that im bothered by the development at the moment.. i think its good that ya'all are designing this from the ground up
|
|
graydon:
|
bfulgham: sure thing
|
|
graydon:
|
fatal: I promised bruce I could have a demonstrable thing (unspecified level of workingness) by end of summer.
|
|
graydon:
|
Y'all can call be a big stinkin' liar if I don't.
|
|
Fatal:
|
heh
|
|
graydon:
|
fatal: might not be much more than a box that says hello though.
|
|
Silk:
|
graydon: what remains to be done in order for that to happen?
|
|
Fatal:
|
graydon: as long as a lot of the underlying stuff is functional, it will give people something to work on
|
| | Signoff: bfulgham (Leaving) |
|
graydon:
|
silk: factoryfinder, a corba lifecycle interface, needs to be written. Then you just make a widget called "helloWidget" which does mesa calls.
|
|
graydon:
|
The tricky part is how to encapsulate mesa state between widgets
|
|
Silk:
|
true
|
|
Silk:
|
state changes are expensive
|
|
graydon:
|
One option is to only export "drawing" commands, and not let the clients change global state (lighting, projection, etc) and then give each widget its own modelling matrix.
|
|
graydon:
|
Push, draw, pop, etc.
|
|
graydon:
|
Silk: that's easiers
|
|
graydon:
|
s/easiers/easiest/
|
|
graydon:
|
But it's not terribly extensible or elegant imho
|
|
graydon:
|
I'm going to talk to a guy who made an open inventor clone
|
|
Silk:
|
it's an interesting problem
|
|
graydon:
|
he's released it under "academic and noncommercial only" license. I want to coerce him to the lgpl / gpl side of the force.
|
|
Silk:
|
most opengl apps are only concerned with themselves
|
|
graydon:
|
silk: exactly. Berlin is an openGL multiplexer, essentially, and openGL really only defines *1* state machine.
|
|
mass-:
|
there is more than one open inventor clone
|
|
mass-:
|
There is the one linked to on teh Mesa page, but there is also one on (I think) www.sgi.com/Technology/OpenGL
|
|
graydon:
|
Fatal: if you speak openGL, I'm sure *any* UI stuff you can do, even utility functions for drawing buttons or that sort of thing, would be very welcome. You can experiment on that without the berlin server running.
|
|
graydon:
|
mass: I found one called "apprentice" -- what others do you know of?
|
|
mass-:
|
hold on, I'll get the other one
|
|
graydon:
|
mass: there's one from the trolls, but erm, well, I'm afraid of them ;)
|
|
Silk:
|
graydon: can we design a 3d ui? =)
|
|
mass-:
|
oh wow. an ie4.0 bug. Never would think I'd see one of those ;)
|
|
mass-:
|
hold on... ok, it is ftp.troll.no
|
|
mass-:
|
afraid?? =)
|
|
graydon:
|
Silk: I suppose. I mean, I'm mostly concerned with speed in mesa. Speed is the big issue right now. In 5 years, speed of 3d will not be a big issue. Right now, a perspective 3d GUI will be about as slow as a mac 128 imho.
|
|
graydon:
|
Silk: I'd be totally satisfied with a "painted polygons" approach
|
|
Silk:
|
right
|
|
graydon:
|
mass: trolls wrote QT.
|
|
Silk:
|
hmm
|
|
Silk:
|
you want to export opengl displaylists through corba, right?
|
|
graydon:
|
Silk: something like that.
|
|
mass-:
|
ahh
|
|
graydon:
|
Silk: If we literally just make each widget a displaylist, I can make that interface in a single night.
|
| | nickgone (marty@sod.student.umd.edu) has joined channel #berlin |
|
graydon:
|
silk: push, callList()m pop. Simple for the server.
|
|
Silk:
|
graydon: I honestly haven't done any work whatsoever with displaylists, but it can't be that hard
|
|
graydon:
|
Silk: How threadsafe is mesa? Not at all, I guess?
|
|
graydon:
|
Silk: no, displayLists are simple I think.
|
|
Silk:
|
graydon: afaik it's getting there
|
|
mass-:
|
so how extensively do you want to use OpenGL? you want to use it for *all* 2d?
|
|
mass-:
|
I'm not understanding where this is going =)
|
|
Silk:
|
graydon: people are working on it.. people are writing multithreaded mesa programs
|
|
Silk:
|
mass-: pretty much, yes
|
|
mass-:
|
ahh
|
|
graydon:
|
mass: I want to be able to run it in orthographic mode so it *looks* like a normal windowing system, and has nearly the speed of one.
|
|
graydon:
|
mass: if people want texturized surfaces and 3d rotation in perspective mode, fine. I just don't want berlin to be "the 3d GUI" -- it will be met with a certain level of ridicule.
|
|
mass-:
|
I get you. What does that buy? I mean, as apposed to just implementing a 2d api?
|
|
mass-:
|
haha
|
|
graydon:
|
mass: just that -- we don't have to implement a 2d API.
|
|
mass-:
|
apparently you havent seen the "windows GDI2000"
|
|
graydon:
|
mass: I have. It's hilarious. I'm sure it'll be a hit.
|
|
Silk:
|
mass-; that thing looks downright scary
|
|
mass-:
|
The windows are all boxes, you can move them closer, and can rotate them on their side so they are a horizontal bar.
|
|
graydon:
|
mass: gotta do something with those idle cycles
|
|
mass-:
|
The scary thing is that they are telling hardware manufacturers that they need to support 2048x2048 textures. They just tell them this, and know the Microsoft power will sway them to start working on it
|
|
graydon:
|
silk: the trick with multithreading is that I would *like* it to be not-too-easy for a client to make the whole system look slow just by uploading a complex displaylist. heh.
|
|
mass-:
|
yes, you don't want things swapping between displays, it should stay on teh current one until it is nice and finished
|
|
graydon:
|
silk: might be infeasable given the openGL model. It seems kinda all-or-nothing.
|
|
Silk:
|
oh, yeah
|
|
Silk:
|
that's one thing
|
|
Silk:
|
I think opengl can only have one rendering thread
|
| | netgod is now known as n3tgod |
|
graydon:
|
silk: yeah, so that might be a problem.
|
| | Silk is considering whether that is a crippling limitation |
|
mass-:
|
It all sort of depends on how Fahrenheit pans out for Windows. Microsoft wants Fahrenheit to be a high-level API, and to be based on DirectX7 for windows platforms. SGI is planning on using OpenGL underneath Fahrenheit.
|
|
graydon:
|
silk: ultimately we were going to have a single "composing" thread anyway to do all the blits. Might be OK.
|
|
mass-:
|
Consumer card manufacturers are going to gear up for whatever Microsoft tells them to; if microsoft doesn't write the OS to support their product, they will go out of business
|
| | Napalm (kclark@dal284.cmpu.net) has joined channel #berlin |
|
graydon:
|
hey napalm
|
|
Silk:
|
mass-; well.. Microsoft is still playing catchup to OGL for now
|
| | Napalm nods |
|
Silk:
|
mass-; i think ms has finally realised that it has to make the api perform in a sane way for it to be accepted
|
|
graydon:
|
silk: yeah, OpenGL is way ahead in mind and market share
|
|
graydon:
|
silk: I'll be really sad if OpenGl suddenly becomes ClosedGL.
|
|
Silk:
|
graydon; it won't
|
|
mass-:
|
yeah. There are a lot of things that you can do in OpenGL that you still can't come close to in D3D. Even Glide, which was written by one guy (Brian Hook) as his first project can do a lot more than DX5, and is faster doing it.
|
|
Silk:
|
the question is whether it'll stagnate once fahrenheit comes out
|
|
graydon:
|
silk: we'll just have to clobber microsoft before that's an issue ;)
|
|
Silk:
|
graydon; my thoughts exactly
|
|
Silk:
|
if opengl can become well entrenched in the next two years, it'll be around for 10 whether ms likes it or not
|
|
mass-:
|
Silk: Microsoft will continue to support OpenGL because it really wants SGI on the NT platform. They don't ever plan on supporting it for normal end-users, which means there will be problems getting consumer-priced cards that support it.
|
|
mass-:
|
but anyways =)
|
| | Signoff: Napalm (Napalm has no reason) |
| | graydon has set the topic: "Berlin meet -- OpenGL Love-In" |
| | graydon has set the topic: Berlin meet -- OpenGL Love-In |
|
mass-:
|
Fahrenheit will be a high-level API. It can be built on top of either OGL or D3D.
|
|
Silk:
|
yep, this ms bashing doesn't really get you anywhere
|
|
mass-:
|
There is actually suppsed to be a first draft of the Fahrenheit API coming out soon
|
|
Silk:
|
I like opengl, opengl is supported under linux, and that's that
|
|
graydon:
|
ok ok ok. I'm going to go mail the apprentice guys and then start coding a displaylist widget under tha assumption that they'll refuse my suggestion. Then I'm going out for birthday cake.
|
|
mass-:
|
ok, have fun =)
|
|
graydon:
|
This means I'm closing the log. Any last words for posterity?
|
|
Silk:
|
graydon; i'll take a stab at doing some opengl widgets under x next week.. got a lot to do this weekend
|
|
mass-:
|
so long, and thanks for all the fish
|
|
graydon:
|
silk: would be much appreciated.
|
|
mass-:
|
look at the Moonlight Creator source, it uses OpenGL for its widgets (dialogs, etc)
|
|
Silk:
|
later
|