udovdh: currently I am installing this other box which will also have a hd2600pro card but which will have two 1280x1024 LCDs showing a 2560x1024 desktop.
libvde: udovdh: :)
udovdh: just another way to test
udovdh: the performance so far of radeonhd on my single monitor setup, as wel as the 'open' nature of the driver, the process, etc made me get the second hd2600pro card for this new setup
udovdh: so: keep up the good work!
libvde: we will :)
libvde: btw... fosdem shedule: http://wiki.x.org/wiki/fosdem2008
ndim: Hi all.
ndim: What state is the source tree in? I have not done a build in weeks, as everything was just working...
ndim: Eh. Bridgman at FOSDEM is great news.
udovdh: Bridgman is which? (in the schedule)
udovdh: ah I see
udovdh: I overlooked
udovdh: any other peopel from here that will attend?
udovdh: tips for a sleeping place nearby are welcome :-)
ndim: udovdh: By now, I guess all the hostels are booked, and hotel prices may become a little less nice.
udovdh: hmmm. I can drive there, but a stayover would be nicer
ndim: udovdh: A suggestion, though, if I may: Do not expect to fine space in a tram headed to FOSDEM's first slot on sunday morning.
udovdh: I will be there with a car
udovdh: or is the parking like hell?
ndim: At ULB campus... no idea.
ndim: In downtown Brussels, it certainly looked like it (but I used public transport last year).
udovdh: in other news: http://games.slashdot.org/article.pl?sid=08/02/02/0236200
udovdh: just need a place to park during the event.
udovdh: can walk a bit
udovdh: but not excessively priced parking places nor distances please
udovdh: I saw the vorst nationaal is relatively close?
udovdh: I parked there for free in 1998
udovdh: ok, got the machine up so far. radeonhd works with one screen. polishing the aps etc
udovdh: gotta do the dual screen stuff tomorrow as well as audio setup etc
Torfbolt: hmm... that's strange... since my xserver update i need two tries to start my xserver with radeonhd...
Torfbolt: xorg-server-184.108.40.206-r2 with latest git radeonhd
z3ro: hmm this atombios stuff is confusing...
rx__: anything interesting?
z3ro: looks like there are separate data tables (these are the ones at rhd_atombios.c:406), but then AtomBios/Decoder.c seems to be some weird mess of table/opcode parsing.
z3ro: so possibly the Decoder.c stuff is for parsing some bytecode that starts with a parameter table or something.
z3ro: there is also this weird EASF table format that I'm not sure about... I guess EASF -> EASy Format
rx__: takes a look
rx__: uh.. where is this easf.h?
z3ro: doesn't exist. I just realized the easf code has been disabled...
z3ro: so all that is left is incomplete parts.
z3ro: maybe amd abandoned this table format during development.
rx__: maybe.. certainly you can ask bridgman about it
z3ro: yeah I might bring it up next time he's around.
rx__: has revenge work been suspended?
z3ro: nope, I've just been busy with real life so I haven't done much work on it lately.
z3ro: I really should add pciid based detection some time.
rx__: no rush
rx__: i was just curious
z3ro: it's actually kind of interesting that noone really uses it, though.
Torfbolt: latest git seems to be broken for me... radeon works, radeonhd doesn't
z3ro: I think it was bad timing that amd decided to release docs at the same time I was writing revenge.
rx__: i would use it if i knew what the output was exactly ;)
z3ro: not that I'm complaining...
z3ro: dumps of the commands sent to the card.
z3ro: and some other stuff
rx__: so the packet0, packet2, and packet3 stuff?
z3ro: yeah. basically those commands program registers on the GPU.
z3ro: there is a good article on planet.fd.o
Torfbolt: Xorg hangs, last line in log is "RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0)"
z3ro: alex's articles.
rx__: yeah i've been following up
z3ro: it would be good for someone to make some images of the structure of the packets etc. that would probably help the text description.
z3ro: but I suck at making those kind of graphics, so... :p
rx__: well this isn't much use w/o the cp microcode though.. right?
rx__: i looked a bit in drm
z3ro: the cp microcode is like the firmware for the cp, but much lower level.
z3ro: afaik all radeon cards use the same command packet format, though.
z3ro: so the microcode is really just part of the hardware implementation.
rx__: but the microcode has to be obtained from amd?
z3ro: yes, only amd would know how to correctly write it.
z3ro: unless someone did some extensive reverse engineering, but even then I'm not sure it's possible.
z3ro: it can be dumped from the blob easy enough.
rx__: i bet the xf86-video-avivo devs can manage to do it ;)
z3ro: yeah all you have to do is get a dump of the kernel module MMIO.
z3ro: or you can extract it from the binary with objdump/dd/etc (but this might be more shady legally)
rx__: guess that will just have to wait
rx__: speak of the devil
z3ro: hey bridgman
bridgman: Hi guys. I got curious about EASF. East Anglia Social Forum was the best I could do
rx__: hello bridgman
bridgman: Where did you see it mentioned ?
z3ro: bridgman: atombios parser code
bridgman: Ok, give me a minute (scratches head)
z3ro: I think it's just another table format (I guessed "EASy Format") but it looks like it's deprecated/ommitted from the parser.
bridgman: Yeah, it's sure not ringing any bells. We basically have two kinds of tables...
bridgman: command tables and data tables.
z3ro: so I guess data tables are like:
z3ro: rhdAtomAnalyzeRomDataTable: UtilityPipeLine
z3ro: rhdAtomAnalyzeRomDataTable: MultimediaCapabilityInfo
z3ro: rhdAtomAnalyzeRomDataTable: MultimediaConfigInfo
z3ro: and the command tables are the ones that include the opcodes (parsed by AtomBios/Decoder.c and CD_*.c)
bridgman: Exactly. There are two main differences between AtomBIOS and normal bios :
bridgman: 1. Most of the code is written in portable bytecodes and interpreter is in C
bridgman: 2 Function calls are finer grained so you don't get stuck with specific modes
bridgman: as an example. Granularity probably needs to be tweaked a bit more for X drivers,
bridgman: based on feedback from Luc & co.
z3ro: I'm just trying to work out how the "calling into bytecode functions/tables/whatever they are called" works.
z3ro: granted I haven't gone through it line by line yet.
z3ro: that Decoder.c code is a bit horrific. ;)
bridgman: You either have to go through line by line or we have to write better docs ;)
bridgman: Again, idea is simple. Set up some workspace for the decoder, stuff any parameters
bridgman: onto it's little stack, then call the parser passing the address of the command table
bridgman: you want to execute. That command table might call other command tables or might
bridgman: just run a bunch of bytecodes and return.
bridgman: Command tables use the info in the data tables; so can the driver
bridgman: There are scratch registers which maintain a common view of GPU state - BIOS
bridgman: commands update the scratch registers and if driver goes round BIOS it must do the same
bridgman: Scratch registers are just a bunch of registers on each GPU which aren't hooked
bridgman: up to anything -- they just provide workspace in a known location
z3ro: yep. I've seen those used for writeback tests etc.
bridgman: Well, I say "known location" -- we moved 'em going to 6xx ;)
z3ro: of course. ;)
z3ro: ok, so let me see if I've got this right: command tables are just a some bytecode to be executed, or calls to other command tables...
z3ro: these command tables expect some data pushed onto the stack when they are extcuted.
z3ro: eg a "set clock" command table might take X clock and Y clock as an argument.
z3ro: for example
bridgman: Yep. For some reason our docs don't call the stack a stack, it's just "a workspace
bridgman: area where the workspace for a called routine is immediately below the workspace
bridgman: of the calling routine", but yeah...
z3ro: I think calling it "a stack" is much less confusing. ;P
rx__: are these like arguments to a script?
z3ro: but yeah, if you're planning to release atombios docs I'd be interested. I saw one of the files refers to some docs.
z3ro: rx__: well, arguments to the bytecode, yes.
bridgman: I guess we should clean up the docs and release them. SuSE got the docs in a pretty
bridgman: scruffy state, unfortunately, then once they got radeonhd running there wasn't much
bridgman: need to make the docs better
z3ro: well if they were good enough for the suse devs they are probably good enough for us to figure out too. :)
bridgman: Yeah, look how much they like AtomBIOS ;)
z3ro: atombios does seem a bit tacked-on to the driver.
z3ro: personally I think it's a good idea. get all the hardware specific tweaks into the bios in bytecode.
rx__: offtopic, is agd5f the only one working on mesa/drm for r5xx+ ?
rx__: on the 3d side of things
z3ro: I think he's working on cleaning up tcore.
bridgman: The SuSE devs tacked it on so we could update it without messing the driver up, so
bridgman: IMO that's a good thing. If you mean "only one working on the 3d docs", yeah it's mostly
bridgman: him with some time from me as well. If you mean "working on the code", I don't think
bridgman: he's touched it yet. Tcore is waiting for me to find the last big email of "scary things"
rx__: yeah.. i was referring to the code drop :)
z3ro: I'm very eager to get my hands on that, too. :)
bridgman: and confirm that tcore is OK to release.
bridgman: I'm going to try to finish the review this weekend. Problem with this job is that
bridgman: big uninterrupted chunks of time are hard to find, and tcore is about 60k lines of code
rx__: hire another agd5f ;)
z3ro: 60kloc is pretty big.
z3ro: I actually thought it would be smaller than that.
bridgman: It's tough -- Alex had a bit of a unique background -- x hacker by night and worked
bridgman: with Intellectual Property stuff during the day
bridgman: I expect there are only a few K of interesting things in tcore so it won't be that
bridgman: bad. The main thing is that it covers the same functions for multiple generations
bridgman: of chips so it's a great source of "what changes from 3xx to 4xx to 5xx to 6xx
z3ro: thats a *very* good thing, imho.
bridgman: to 7xx (oops, forget that last part ;))
bridgman: Collecting the same thing for 3d is tougher... the programming model doesn't change
bridgman: that much but the "optional things you can do to go faster" change a lot, so the changes
bridgman: in our driver from gen to gen are huge. What we're finding is that the changes needed
rx__: that begs the question.. at what level does most errata appear
bridgman: for a first cut 3d driver that can run Compiz etc... are a lot smaller
bridgman: Errata tend to be at the two extremes -- basic stuff like synchronization, and
bridgman: cutting edge stuff like having the driver diving into the pipelines and fiddling things
bridgman: that are already running in order to get the last bit of performance
bridgman: Most of the errata cleanup isn't too bad though... the writing is remarkably
bridgman: diplomatic these days, no personal insults or questioning intelligence of the
bridgman: block designers
bridgman: We can call it "driver writing tips" and it all looks good
z3ro: I hope that we'll still get to see some of those performance tweaks in the open source driver... I'm after comparable performance to fglrx...
bridgman: Ahh, that's a different story. 20k lines gets you compiz and google earth. 2M lines gets
rx__: yeah it sounds like getting into game-specific tweaks too
bridgman: you performance comparable to fglrx. How much free time do YOU have ?
rx__: 2M lines.. ugh
z3ro: bridgman: well, really most of the time is spend figuring out *how* to do it.
z3ro: not actually implementing it.
z3ro: so when docs are released, it hopefully wouldn't take too long.
bridgman: One thing that surprised me -- I've been involved in "close to metal" engineering fo
bridgman: 30+ years now and you still end up with 5-20 lines of well designed, documented, debugged
bridgman: code per developer-day. And they call economics the dismal science.
bridgman: I think 3d will happen surprisingly quickly once we release docs.
z3ro: yeah, I agree.
bridgman: Realistically, we're talking two iterations here. The first will be fast, crude,
bridgman: based on r300 dri, and will work much better than you might think but will never go
bridgman: past fixed function. Second iteration will be careful, written largely from scratch,
bridgman: based on Gallium, and will be able to go as far as people have time
agd5f: r5xx and r3xx are similar enough that the older chips should benefit as well
bridgman: I don't care so much about that second iteration other than making sure it
bridgman: can happen. IMO open source drivers lose some of their value if they are so
bridgman: stinkin' big that nobody can understand or maintain them
z3ro: well, I don't expect we'll get into per-game tweaks or custom vert/frag progs, but I'd like to see the driver run as fast as possible.
z3ro: so hopefully that includes some of the optimizations like hyperz and all the other buzz.
bridgman: rx: exactly. That's why we did a from-scratch reimplementation of the openGL driver
bridgman: and are now in the process of putting largely new code inside the X portion
bridgman: No sarcasm. We inherited fglrx when we picked up Diamond/FireGL and at the time
rx__: that.. unfortunately doesn't sound like very good news for fglrx users
bridgman: it was a great workstation driver (very fast, I have to say that) but totally
bridgman: useless for anything else. We managed to housebreak it quite a bit and make
bridgman: it someone useable for consumer but it certainly wasn't designed for that
bridgman: Now we're at the point where we don't need to compromise WS performance to get
bridgman: consumer features & stability but there's still a few months work to get that all
bridgman: out into public hands
rx__: worst case scenario.. end user experience is definitely not going to look pretty for the coming months
rx__: at least on fglrx side of things
bridgman: Actually end user experience is getting better quickly. We got caught by AGP cards
bridgman: because we had already announced "support for 6xx" before we realized there were
bridgman: going to be AGP products, so in hindsight we should have announced "support for 6xx PCIE"
bridgman: It sucks to be an AGP user right now, at least 6xx AGP, 'cause we haven't released
bridgman: support for that yet, but I think things are improving pretty quickly otherwise
agd5f: AGP death can't come too soon
z3ro: bridgman: btw, I'm curious, will you (amd) be releasing debugging/performance counter info along with or after the 3d docs/code?
glisse: bridgman: do you have people working on gallium driver ? :)
bridgman: Amen to that. I'm doing my part -- my AGP box died ;)
z3ro: I think this will be key to making a good fast driver too.
bridgman: Nope, I was going to talk to you about that ;)
z3ro: even on a CPU it's hard to find where your bottleneck is witout actually profiling the code.
rx__: glisse; looking for a way out already? ;)
glisse: bridgman: well just curious to make sure i not doing code that is going to trash
glisse: as i am short on time i prefer not doing so
bridgman: z3ro: we're not filtering the performance counters out of the info we release
z3ro: good :)
bridgman: but there's not much docco on actually using them
glisse: rx__: oh there is no way out from my lab, we are a bunch of phd student stuck in the third basement for years with no way out =)
bridgman: glisse: that is the economic engine of the first world ;)
glisse: our director throw some food to us and if we nice enough we got beer
rx__: paints a picture of a window with sun shining in your lab
bridgman: z3ro: hyperz is another of those things where we'll provide the programming info
bridgman: but there's a lot more to it than just turning it on. There are a bunch of things
bridgman: games can do which either confuse or just plain break most of the z-related optimizations
bridgman: so you really need to deal with them on a game-by-game basis for best performance
bridgman: The basic stuff can just work, but each new chip adds hyperz2, 3, 4, 5 etc... and each
bridgman: new addition brings more performance but more complexity in the driver
bridgman: It's kinda hard to filter out triangles at the head of the pipe if the Z is being
glisse: well i am more curious about AA things bit hard to understand from register
bridgman: computed down in the shader
bridgman: Um... yeah. The AA stuff is hard to understand from the internal design docs too ;(
z3ro: bridgman: yeah, there would be cases where it must be disabled or adjusted per-game... but this can be added eventually.
bridgman: It can be added eventually if you turn it off by deafult. If you turn it on by default
z3ro: I guess the initial implementation would just be a basic "meet all these condidtions and we enable it, otherwise, disable"
bridgman: then you kinda have to add it on day 1 ;)
bridgman: Problem is that you have to sniff the shaders to know if you can disable it
bridgman: make that "enable it"
rx__: chicken and egg problem?
bridgman: Or you can app detect but that is evil as we all know
bridgman: Hey, is it still evil if an open source driver does app detection ?
bridgman: I mean does the goodness of the open source trump the badness of the app detection
bridgman: or what ?
z3ro: hmm in gallium we can proabaly do something in the tgsi code.
glisse: bridgman: well we can add app profile
z3ro: but this might be a bit too high level maybe.
glisse: this is totaly different things ;)
rx__: app profile != cheating
bridgman: Now THERE'S a good topic for an XDS talk ;)
bridgman: rx: then how come everyone got so steamed when we did it ?
bridgman: We didn't even put in shaders that gave different results ?
glisse: bridgman: you use the wrong name, it's that simple ;p
bridgman: Unlike (PR guy comes with ductape)
z3ro: bridgman: benchmark results, and hiding the fact that it was done.
bridgman: I don't think we did it for benchmarks, just for games. It's not my fault that
rx__: i don't think there's a good way to spin the PR
bridgman: people use games for benchmarking ;)
glisse: well gamer are the one who drive this industry
bridgman: So only for open source, huh ?
bridgman: Yeah, but our shaders *did* give the same results, bit for bit...
bridgman: They just weren't optimized for... um.. another GPU
z3ro: hmm yeah. I guess it's walking a bit of a fine PR line.
bridgman: We saved the game developers money
z3ro: between "cheating" and optimization.
glisse: i am more for a scheme like driconfig maybe a bit improved one so that it will be up to gamer to find out best tweak for their game
z3ro: I mean, optimization is a cheat, really.
glisse: at least they will have some fun finding out :)
z3ro: (but in a good way)
glisse: and this can also have benefict effect on game programmer (damm i am dreaming :))
rx__: cheating would be sacrificing image quality for optimization IMO
bridgman: Right. How about optimizing instruction sequence for faster execution on your GPU ?
rx__: that's purely optimization.. not a cheat
bridgman: Whew. That's where I try to put the line.
bridgman: OK, I gotta run. It's getting dark and I haven't finished digging out my driveway
z3ro: ok, thanks for the chat. :)
rx__: thanks for all the information
bridgman: Sooner or later someone's gonna come over and right now there's a couple feet of snow
bridgman: at the end
wirechief_: snow blowers work nice.
bridgman: Talk to you all later. If someone knows a good place to stay for FOSDEM pls sing out
bridgman: I have a snowblower, but driveway is >500 feet
bridgman: I kinda live out in the sticsk
dvandyk: bridgman: if you want to stay cheaply there is a YMCA-like thingy at place madou
wirechief_: me too 165ft but ya gotta love it.
bridgman: It seemed like a good idea at the time (in the summer ;))
bridgman: dvandyk; thanks ! I figure I won't be spending much time there
z3ro: wishes he had money to get to fosdem. :(
dvandyk: bridgman: however, it's more for like "cheap stay for poor students"
wirechief_: wishes they make a video of it.
z3ro: that would be good.
dvandyk: bridgman: some of the gentoo people go there every year
bridgman: Should be fun. I speak one of the official languages badly and the other not at all ;)
dvandyk: i'm trying to remind myself of the name
bridgman: I'll see if I can scrounge a camera this time. I borrowed one for XDS but left at home
bridgman: OK, I'd better run. Bye
wirechief_: >500 ft driveway, needs a blade on a tank.
bridgman: before I forget... I found EASF in our source tree. Seems to be something like
bridgman: "something ASIC Setup Function". I figure "Extended ..."
dvandyk: bridgman: Auberge Jacque Brel, it's a youth hostel rather than a hotel...
bridgman: Doesn't seem like we ever used it for anything
z3ro: hmm interesting. so I guess it's probably not even used on production chips.
bridgman: dvandyk; thanks -- I would not be mistaken for "youth" these days ;)
bridgman: Outa here
dvandyk: bridgman: hehe
z3ro: ok, cya.
glisse: z3ro: benh is going to cleanup atombios this week
z3ro: glisse: I already cleaned up my tree a lot (mostly the Decoder.c file)
glisse: z3ro: basicly there is very few files really needed and the script things is prety simple, i don't know to which extend benh will clean but i will likely do some more cleanup so this match kernel code quality
xAFFE: its very nice to see that there is so much work done on the driver :)
z3ro: glisse: ok, if you get it done before me, let me know.
glisse: z3ro: well first things we are interested in are endian correctness so big chunk of accessor functions for script & data table
glisse: z3ro: well i wanted to tackle this during the last week but i missed time
glisse: so i will wait for benh first fight with that :) but we could reuse our decoder cleanup
z3ro: I've already started cleaning it up, so if you want to grab my code? (note I have not tested it yet. I'll do that today some time, but it should work)
glisse: well as i said benh will focus on data parsing but i will ping him so he might start from your code if you put somewhere
z3ro: ok. I'm still cleaning it up right now, but it's looking a lot better.
glisse: dammm there is so much channel to talk about radeon now :)
z3ro: I guess there isn't any problem killing all those unused defines (easf_format, uefi_build, etc)
z3ro: or does benh want to keep those?
z3ro: uefi is some firmware interface thing (probably left over from this code being shared with the code they put in the bios rom)
glisse: don't know, but i guess the aim is also to be able to easily get update from amd so to not differ too much from the original code
z3ro: hmm well my clean up might be too aggressive then.
glisse: z3ro: uefi exist (apple :)) and will likely replace bios sooner or latter
glisse: z3ro: well best solution would be to have some script using sed|perl or whatever to do most of the cleanup iin an automatic way
z3ro: glisse: is this for the driver parser too then? or just for when they compile a bios image?
glisse: just when they compile bios image
glisse: at least i don't think parser care about being run by uefi things or not
z3ro: hmm it's just stuff like if !UEFI then add bios_image pointer to variable
z3ro: so I guess uefi already includes this offset or something.
glisse: well i got to run bbl
z3ro: ok, bye.
z3ro: ok, bye.
dvandyk: hm, can somebody help me with a slight radeon9600 problem?
dvandyk: i just switched to using xf86-video-ati from fglrx
dvandyk: now my maximal resolution is 640x480
dvandyk: dvandyk@phi X11 $ xrandr
dvandyk: Screen 0: minimum 320 x 200, current 640 x 480, maximum 640 x 640
dvandyk: sorry,. 640x640
rx__: try #radeon
dvandyk: i will
rx__: for xf86-video-ati issues
marcheu: someone tell bridgman that their optimizations were indeed lowering the quality, which was the mistake (brilinear, forced texture compression, forced texture resampling to 16 bit)
marcheu: I don't think end users care about optimizations that don't change their screenshots :)
marcheu: also hyperz can be easily dealt with in an application-independent way, just disable it when the "direction" of z testing changes
rx__: he reads logs.. so i'm sure he got that message :)
marcheu: heh, ok
rx__: you did the initial RE work for hyperz right?
rx__: to understand it at such a low level.. that's nuts :)
marcheu: some people like RE, it's kind of an intellectual challenge
rx__: yeah .. i wish i knew where to start
rx__: the work you guys do is fascinating
marcheu: heh, FWIW I started RE when I was cracking games on the amstrad CPC :)
rx__: that's awesome
rx__: hi bridgman again
bridgman: marcheau; no argument there. Oddly enough we didn't get flamed so badly for those ;)
marcheu: because the PR was strong, and they were called "catalyst AI" :)
bridgman: Oh, that ;(
bridgman: I sometimes think we PR-ize the wrong things ;)
marcheu: I think brilinear predates catalyst AI though
marcheu: well when I was RE-ing the texture formats it was surely funny
bridgman: Yeah, most of those were called fairly. It was when we were app detecting and
bridgman: plugging in bit-for-bit identical shaders that we got the worst abuse though
bridgman: dang, burned another pizza
bridgman: sounds like a fair # of you are going to fosdem ?
marcheu: yeah european guys are
marcheu: because it's so central, most of us can get there in 4/5 hours
bridgman: must be nice. First time someone talked about "going to a party in Germany"
bridgman: it seemed really odd to someone living over here
marcheu: uh ?
bridgman: I can't get from one major city to the next in 5 hours
marcheu: yeah, it's a little more than a 4h drive from here :)
bridgman: very civilized ;)
marcheu: it's also very nice if you're into food/drinks
marcheu: chocolate & beer are probably the two must-sees over there :)
bridgman: yeah, it's hard to get belgian beer here. I've only seen one bottle of Chimay blue
bridgman: in my life
marcheu: weird, I have a couple in the fridge ATM
bridgman: auggh, don't tell me that ;)
bridgman: it was like "nectar of the gods"
bridgman: beerfest is Friday night ?
marcheu: I'm not fond of that one
marcheu: well it's every night in brussels
marcheu: they have a big number of typical, cosy bars
bridgman: sounds good. Is everyone showing up friday night ? Flights seem to get in
bridgman: early AM from canada/us, so I need to either come friday AM or saturday Am
marcheu: I'm showing up wed or thu
bridgman: ?? when does it start ? I was thinking it started on saturday
marcheu: it does, but I'm doing the tourism thing :)
marcheu: (a friend of mine lives over there so we'll go test every bar for you)
bridgman: good idea. Hmm.
bridgman: Ahh, great. I will monitor IRC religiously those days
bridgman: Guess I better go work on a good-sounding writeup to ensure my travel req gets approved ;)
bridgman: cu later
marcheu: well fosdem is interesting because you reach a wider audience
marcheu: XDS & the like are very technical and small
marcheu: fosdem is 2000/3000 people
bridgman: I'm not sure I know what to say to a larger audience. I *liked* XDS size ;)
marcheu: well there are lots of parallel sessions, that's the trick
bridgman: Oh good... so I don't need a background on my slides or anything ;)
marcheu: a couple of main tracks, and the devrooms
bridgman: Ahh, so devrooms are part of the plan, not "something unusual"
marcheu: yeah totally part of the plan, there are 10 of those
marcheu: this year we got a bigger one, inside the main building. call that improvement :)
bridgman: In the main building is definitely an improvement. When you're in another
bridgman: building it always seems to rain
marcheu: I think our devroom has ~100 seats or so, we'll see how wide the audience is :)
bridgman: Well, I can think of at least 3 people ;)
marcheu: recalls the ultra-packed Xgl 2006 talk
bridgman: I think you get the big crowds on the first announcement or when people think
bridgman: there's going to be a good fight. AMD this year is boring ;)
marcheu: I'm not fighting against you, or anyone that 1m95 for that matter :)
bridgman: Yep, see, small crowd ;)
bridgman: we obviously need some new initiatives that half the X crowd doesn't like
bridgman: I'll see what I can think of ;)
bridgman: Better go... the curse of dial-up is that you actualy have to disconnect