--> anholt (~anholt@c-24-21-18-195.client.comcast.net) has joined #dri-devel --- ChanServ gives voice to anholt <-- sunny has quit ("back uptown") can anyone tell me how to set a breakpoint on r200InitDriver for instance? The problem is that the .so isn't loaded at first and when it is (and gdb stops because of the FPE) I'm already past that function. Setting a future breakpoint also doesn't seem to work. --- GrifGone is now known as Griffon26 break on the function that calls r200InitDriver and then step <-- _MacGyver_ has quit ("Leaving") is it not possible to break on the init function itself? I'm just getting started, so I don't even know what function calls it yet =] not as such no. are you familiar with how dlsym() works? it returns a pointer to a named symbol yeah all the various symbols in *_dri.so (except for one which i forget but which i know is on the wiki somewhere) are resolved by libGL with dlsym instead of at link time I see that the r200 function pointer is filled in in a common structure which is called from dri_util.c so the dlsym stuff is even higher up in the tree then? actually that's sort of a lie, sorry. libGL doesn't do much dlsym'ing but it does call the driver-dependent functions through a structure of function pointers right, saw that which means you can't set a breakpoint until the symbol is loaded int he processes' address space so. you should be able to set a breakpoint on dlopen(), run until you hit that, finish that call, and then set a breakpoint on r200InitDriver no idea what gdb's breakpoints "pending on future shared library load" are then it can do those? it says so if it doesn't know the symbol, it asks me if it has to make it pending blahblah but if I choose "yes", it doesn't seem to work you might get away with LD_PRELOAD but I didn't read everything you said, so maybe I'm totally silly here, ahem :) --> sroland (~sroland@80-218-22-197.dclient.hispeed.ch) has joined #dri-devel sounds like something that could work... lemme just find some docs on it LD_PRELOAD=/path/to/your/r200_dri.so gdb `which glxinfo` and then see if the symbol is defined nope the why don't you just break __driUtilCreateNewScreen and step ? (yes I know it's lame :) I thought that was in the same .so --> Grievre (griever@ool-18bda512.dyn.optonline.net) has joined #dri-devel I'm not going to miss the irc meeting this week! Grievre: what time is it? Griffon26: __driUtilCreateNewScreen isn't in a card-specific .so 3:20 like 40 minutes before it starts, right? what's that in CET? =] Griffon26: more like 1:40 minutes befire whoops Grievre: more like 1:40 minutes befire marcheu: that function is in my r200_dri.so Griffon26: euh... something like.. 11:20? griffon26@griffon27 ~/projects/opengltest/src> nm /usr/X11R6/lib/modules/dri/r200_dri.so|grep CreateNewScreen Griffon26: yes sorry I'm using solo builds marcheu: doesn't it start at 4 EST? solo builds? oh wait 4 EST is 5 EDT so I guess it changes for DST? or rather doesn't change Grievre: it starts in 1:40, and I don't know what EST is :) ok, same as last time then EST is UTC-5 EDT is UTC-4 I think Griffon26: mesa-solo (a.k.a miniglx) Griffon26: a mesa build that doesn't need Xfree to work (or any X for that matter) okay well if people are already here ic I just apt-get updated X, then tried manually re-copying my DRI libs. Didn't work out to well too anyway i cvs upped dri and mesa, then rebuilt and reinstalled and started X again and... now font anti-aliasing is dead, and I've lost my numpad and windows keys (?!) i suspect our DDX drivers are starting to rot. we need to sync. I think I blew away some .so file when trying to hax DRI back in after the update, I just need some general pointing as to which packages I should reinstall also i'm tempted to start pushing the in-Mesa build process for users... in-Mesa build process? Grievre: try this. reinstall x{org,free}, then check out Mesa and do "make linux-dri" hm I don't need what's in the DRI X tree? that'll give you new libGL* and *_dri.so in Mesa/lib that's the idea ;) you're my guinea pig, this is the in-Mesa build process i mentioned I prefer not to use my only desktop machine as a guinea pig heh well I'm already running debian unstable and a cvs version of DRI so perhaps I'm beyond that you can test it without damaging anything. i'll even tell you how, since i'm such a nice guy ajax: can X.org/fd.o X be installed in an entirely seperate tree as Xfree? easily, and not break? wait, in-Mesa build gets us a DRI libGL, too? ajax: If the mesa tree provides libGL and *_dri.so, what does the dri/xc tree give us? anholt: think so yeah, at least that's what's in my /dri/tinderbox/Mesa/lib Grievre: DDX drivers. ajax: what's DDX? Grievre: DDX is basically "everything hardware-specific that isn't 3d". 2d, memory management, resolution switching, etc. "device dependent X" oh bummer, I also can't set a breakpoint in libGL.so before it runs... seems I'm doing something wrong. Is there nobody here who uses a debugger? dri/xc also gives us the server-side modules lib{dri,drm,GLcore}.a ajax: so does DRI's ddx have anything the xfree tree doesn't? Grievre: DRI's ddx has better 3d support for some things (IGP radeon for example), but also more 2d bugs hm does indirect have to = software? i.e. can we do hardware-accelerated indirect rendering no, it doesn't, but currently that's the case accelerated indirect is possible, but the DRI code can't do it yet for a variety of reasons Griffon26: i've never had problems setting breakpoints in libGL why is software GL rendering done in X and not in the app speed? you can do software rendering on either end actually heh I wanna try software quake... but it's so slow under X due to the fact that you can't change X's color depth on the fly (so, even fullscreen, it has to do 8->32 conversions) --> idr (~idr@bi01p1.co.us.ibm.com) has joined #dri-devel afternoon idr --> agd5f (~agd5f@dsl093-100-212.wdc2.dsl.speakeasy.net) has joined #dri-devel so, I still have that pending question about 3d texture support on r100 : I need to send data to the 3rd tmu (texture width), but I'm not sure how it'll work since the radeon 7000 for example has no 3d tmu ajax: Hello. marcheu: you should only need 2 stages one ofr width and height and one for depth but these are stages 0 & 2, doesn't that mean tmu 1 & 3 ? marcheu: hmmm... are you sure VE only has 2 tmus? maybe they virtually support 3 via a loopback somehow <-- jg has quit ("bye bye...") agd5f: I've read that vu has only 1(!) tmu, probably on the dri wiki agd5f: so that's what I thought : that tmu is virtual, but then you see the problem : how to initialize it properly if it doesn't exist ? marcheu: Delphi3D indicates that 3 TMUs are supported in OpenGL. http://www.delphi3d.net/hardware/viewreport.php?report=1029 marcheu: You do it the same way and the hardware makes it work. marcheu: It's the same way with the 9200 in the R200 driver. 7000 has 3 tmus, but not in DRI r200 has like 6 but also not in DRI Grievre: Details, details. :) Grievre: hah, maybe that's limitations from the dri and not from the card marcheu: nah, you think? :) marcheu: Yes. I saw it written on the ati page, as it was about hardware I thought it was an hardware limitation ok, fine shouldn't that be a hardware limitation? meh. marcheu: whether or not the hw actually has 1 or 3 TMUs the same driver just works on all r100 well, english is obviously not my native language :) --> paproch (~jrosik@phobos.rp.vline.pl) has joined #dri-devel ok, so the next question is : do you agree that the logical first step to 3d textures is to get 3tmu to work ? marcheu: That's probably the best route to go. marcheu: You should look through the dri-devel archive on http://marc.theaimsgroup.com. idr: yup, I already got that patch marcheu: People have done patches to support the 3rd TMU before, but they are WAY out of date by now. marcheu: Okay. --> fxkuehl (felix@212.144.10.77) has joined #dri-devel Did someone look at the blend func/eqn separate patch I wrote? http://marc.theaimsgroup.com/?l=dri-devel&m=108456276617055&w=2 If so, could someone commit the drm/dri changes (really trivial)? sroland: I skimmed it, but I haven't had a chance to dig into it. sroland: I should be able to play with it tomorrow. sroland: I won't be able to commit your changes, though (against IBM's rules for me). sroland: you can probably get DRI/DRM commit access if you want. I'd check it in myself, but I don't have recent tree handy at the moment agd5f: ok. I don't think I'll really need commit access again in the future though. sroland: you never know ;) agd5f: true enough ;-) --- Griffon26 is now known as GrifGone --> keithw (~keithw@adsl-213-78-159-49.oneteldsl.net) has joined #dri-devel --- ChanServ gives voice to keithw keithw: Hey! Long time no see. :) Hi... Though I'd come & see what I've been missing out on... thought so, can I just ask daniel stone to add me, or is someone else handling it nowadays? sroland: email to sitewranglers@ keithw: hey! sroland: eric anholt can add you too keithw: So, I'm doing making i830 changes for awhile. s/doing/done/ ajax: ok agd5f, sroland: You're talking about CVS access, right? keithw: yeah keithw: yes, for drm/dri keithw: some one-liner defines to commit ;-) I've got a bunch of bugs that are still present :/ brb Hi all. I havn't received any feedback about my DRM questions yet. Was it a bad time to ask? ;-) And sroland is Roland Scheidegger? In which case, it's fine with me. I'm beginning to yearn for the sf.net days when we had a "process" for granting access. keithw: yes that's me. keithw: There is a process, it just...uh...less formal. :) keithw, idr: it never seemed that formal to me ;) Well, we could at least do it ourselves & not be dependent on an admin who, nice as he is, isn't deeply connected with the DRI project. I'm a little concerned that things could be slipping slighly out of control. (Not that this is any reflection on Roland or anyone else - I'm more than fine for you to have CVS access) Anyway. Enough of that - probably just a symptom of me being stretched by work & less in touch with the DRI project of late. Can I ask about a visual glitch I've noticed? keithw: They ever gonna let you back at open-source work? Your contributions are missed. fxkuehl: I think the issue is that you're really asking questions best answered by kernel developers, not necessarily by graphics hackers... keithw: should be less of a problem now that Eric is back? idr: Historically I've done lots of work closed which is then opened up when the driver is "released". Expect to see that continuing. keithw: Cool. I'll be waitin'. :) keithw: I was hoping someone with experience in hacking drm drivers (MrCooper?) could answer some of this :-/ idr: Additionally, with the merge of Mesa & DRI, I feel that the stuff I'm most interested in is in the tnl/ module, either fixing my earlier cruft from the '99-'00 period of ancient history, or making brand new cruft. Can I ask about a visual glitch I've noticed? (restate) Grievre: Ask away. Grievre: go ahead :) thanks :) well I've found if I switch to another virtual terminal and then back to X, all GL apps will start looking weird walls flicker etc until I restart them Are you using page flipping? yes Grievre: Let me guess...this is on R200 or R100, right? r200 radeon 9000 pro 2x agp never happened on the r100 Grievre: Yeah...this is a known issue with pageflipping. also R200 still refuses to hog CPU when I want it to even setting quake at -19 priority, a CPU spike in another app causes FPS drops Grievre: Are you on a 2.6 kernel? yes but this happened in 2.4 Grievre: That's a known issue too. :( and this never happened with the r100 Grievre: I've been looking at a way to fix it by replacing the current DRM locking mechanism with a futex and a "last context" tag. it doesn't have anything to do with sched_yield? Grievre: I'm especially interested because I'm going to be moving to 2.6 pretty soon. :) Grievre: It was everything to do with that. :( Grievre: The sched_yield calls were put in to prevent on GL app from starving other GL apps. s/prevent on/prevent one/ okay but I'm only using one GL app I WANT it to starve all other apps people playing games generally do Grievre: Right. On 2.4 the semantic of sched_yield was different, so this was an okay hack. On 2.6, it sucks. :( The window manager or some app like a clock or animated doo-dad is possibly causing the X server to contend with your game for the lock. sleep(0)? keithw: I know what it is, several apps (most horribly gaim) have occasionally 40%+ cpu spikes Grievre: The current DRM locks are just "dumb" spin-locks. sched_yield calls were added to emulate a sleep-lock. The real fix is to use a real sleep-lock. On 2.6 and later 2.4 kernels that's a futex. keithw: The problem is that on 2.4 sched_yield meant "I give up the rest of my timeslice." On 2.6 it means "I give up the rest of my timeslice, and I am super-low priority." --> sunny (sunny@sunny.cloaked) has joined #dri-devel idr: doesn't sleep(0) have the 2.4 sched_yield meaning? Grievre: I don't think so. There is a difference, but I don't remember what it is... ouch. this memory management thread is giving kmail fits --> cheako (~cheako@c-24-245-9-227.mn.client2.attbi.com) has joined #dri-devel Grievre GrifGone Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs; Con Kolivas' isochronous scheduling patches help for that here punishes them even if they're -18? idr: The current DRM lock isn't necessarily a spinlock - when the contended state is hit, the userspace code calls into the kernel. It should be possible to implement whatever strategy for dealing with contention in that ioctl. heh. it turns out task scheduling is really freakin hard to do right. ajax: BTW, I don't think the libGL built by the Mesa linux-dri target can load the DRI drivers Grievre GrifGone Grievre: not sure, have you tried chrt? chrt? keithw: The problem is that when you unlock it, you don't know if you need to try and wake-up any sleeping processes. idr: By changing the behaviour of the ioctl, backwards compatibility could be maintained... "no manual entry for chrt" idr: Yes, when you unlock a contended lock, you still use an ioctl. MrCooper: pretty sure it can. let's check. hm keithw: Hmmm.... question Grievre GrifGone MrCooper: oh dear. linux-dri target doesn't seem to build libGL at all! if I use a vanilla X server rather than the DRI one, what do I lose? Grievre: it's in the schedutils Debian package ajax: How could it? ajax: makes sense idr: well we'd like it to, wouldn't we? i mean this is the Mesa client drivers we're building... I ask question^^ Grievre: that's not a question that's easily answered in one line ok MrCooper: okay what do I do with chrt? heh Grievre GrifGone Grievre: give processes realtime priority howww? man chrt I see nothing that looks like realtime ajax: The libGL that goes with the *_dri.so drivers is 100% "window system" dependent. The libGL for XFree86 is vastly different from the one for DirectFB. Grievre GrifGone Grievre: SCHED_FIFO okay heh ajax: What I'd like to see is the dri drivers built by Mesa work correctly with the libGL.so from each window system. ajax: There is the confusing fact that Mesa originally build a libGL.so to work with unextended X11. Actually it used to be called libMesaGL.so, but that's ancient history. BTW, is nobody else seeing the problems I posted about the linux-dri r200 driver? MrCooper: no r200 here, sorry MrCooper: I don't have a big-endian box. :( * idr misses his 7.14MHz 68010... yeah, I suspect it's architecture rather than driver specific keithw: that does sound like a nice idea. should i be foolish enough to ask what the blockers are there? not sure how endianness would cause the effects I'm seeing though MrCooper: Have you compared the compiler directives used by the two build environments? MrCooper: Well, I do have a b-e box, but, thanks to XFree86's "brilliant" PCI probing, I can't even get X to load. I can MrCooper: okay chrt -f -p does nothing it stays at SCHED_OTHER 't make it find the graphics card in PCI domain 1. :( Grievre GrifGone Grievre: try chrt -f 99 ajax: idr posted a strawman patch a week ago for merging X11/DRI and linux-solo * ajax greps... keithw: not closely; the other usual suspect would be char signedness, but I'd expect different effects from that as well... MrCooper: How do you think signedness issues could have been introduced in the new build? keithw: the X trees aren't clean in that regard so they build with -fsigned-char MrCooper: Is it worth trying the experiment of adding that flag to the configs/linux-dri file? <-- Grievre has quit (Read error: 54 (Connection reset by peer)) keithw: I guess so :) keithw: ah, found it, thanks --> Grievre (griever@ool-18bda512.dyn.optonline.net) has joined #dri-devel That worked great in the sense that I got a constant 72 fps (the cap) however it was broken in the sense that the computer didn't accept any input so I had to reboot you seem to have forgotten that the program outschedules X, which has the keyboard hooked :) had to s-u-b Heh... idr: also, is a linux-dri driver supposed to work with the libGL from the DRI trunk as of 2004-02-28? Didn't here when I last tried MrCooper: so..? MrCooper: The ones built from DRI CVS should. The ones built with my patch won't. They will require an updated libGL. MrCooper: I guess what's missing compared to XFree is that Imake does some auto-config stuff, whereas we've got a pretty much static config & rely on the user choosing the right one. man you crash my system and then ignore me :/ MrCooper: Actually....2004-02-28 should be new enough...hmmm... Grievre: First naive idea that comes to my mind is to give the Xserver real time priority as well ;-) fxkuehl: chrt doesn't seem to work on already-running processes Grievre GrifGone Grievre: I use chrt as normal user and get isochronous scheduling isochronous?! oh wait see above you meant for me to do it as a normal user? MrCooper: see above? Grievre GrifGone MrCooper: if you notice, I just rejoined because the command you told me to enter made my computer hang Grievre: calm down; I told you about isochronous scheduling before okay... hm Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs; Con Kolivas' isochronous scheduling patches help for that here what's isochronous? Mkay, I think I'm going to head off. so, since we've got a fair quota of people here: anyone have an opinion about moving to fd.o's bugzilla that they haven't expressed yet? ajax: I'm ok with the idea. Grievre: I'm not sure exactly what it means in this context, but it usually means that you guarantee a process a certain percentage amount of bandwidth per time slice. keithw: cool. i know i'm fairly new to this game, i'm not trying to piss people off by gratuitously changing things or anything Grievre: So, with USB, an device can request isochronous transfers of X bits/second. ajax: It's also worthwhile setting up something so that bugs reported on X.Org's database which pertain to DRI code get forwarded to us. That's what happened with XFree86 bugzilla, I've got no idea why the stream of reports from that dried up. but, all the opinions i've heard have been either indifferent or positive keithw: i believe i can rig that... ajax: I doubt you're going to make anyone mad by improving our bug tracking. :) ajax: The one problem (it only happened with one bug, actually), was that it turned into some kind of alternate mailing list where people had discussions amongst themselves, but each & every post was echoed to the dri ML, but DRI ML users couldn't reply (ie you had to go into bugzilla). It was pretty rooted, really. ajax: I doubt that problem's fixable, but it would be great to have a bug database that understood that a reply to a generated email should be treated the same as adding a new comment to a bug. keithw: Someone needs to make a bugtracker that sends bug "updates" to a mailing list, but if you group reply, your reply gets added to the bug. Basically, a bugzilla that can get / archive e-mail. keithw: Hey! ;) shazam! --> adamk (~adamk@pcp04364911pcs.glstrt01.nj.comcast.net) has joined #dri-devel indeed. i'll see if someone's cooked up some bugzilla-fu for that idr: debbugs is mostly e-mail based idr: unsurprisingly, it has its own quirks though right then. so, details now. do we want DRI and Mesa as separate products, or is that just silly? ajax: There are parts of DRI that aren't in the Mesa tree. ajax: I think it makes sense if we restrict the DRI product to libGL and the server side GLX stuff. idr: But can a user reporting a bug be expected to know which is which? keithw: -fsigned-char doesn't seem to make a difference keithw: True. :( Is it possible to re-assign a bug to a different product? it certainly is Okay. If a user submits a bug on the wrong one, we can change it. cool. next: how much of the existing bug database should i worry about importing? i see an open dri bug from january 2000... ajax: There's a LOT of old stuff in there. ajax: I've tried to follow up on some of it. Most of the time the person that reported the bug doesn't even have the hardware anymore. :( <-- adamk has quit (Remote closed the connection) i was considering an arbitrary cutoff (for DRI anyway) of "the first fifty with non-anonymous reporters" The Mesa bug database is active & maintained. The DRI one is dead & was replaced by XFree86 bugzilla. ajax: I was going to suggest closing anything more than 6 months old as "stale" (or whatever it is). ajax: You will need to work closely with Brian Paul on this as he does keep close tabs on the SF Mesa bug database. keithw: yes, quite. Mesa's db looks much cleaner than DRI's does. idr: well i can't close anything on sf, but i can at least not add them to fd.o someone else will have to close off the sf trackers (and i've got a link for how to do that around here somewhere) * anholt returns was busy... using the r200 driver did sroland get his account hookup yet? looks like it, i see a /home/sroland OK, now I'm really heading off. Night all. anholt: I haven't sent an email yet. But I don't mind it if you just add me to dri/drm without one ;-) <-- keithw has quit ("using sirc version 2.211+KSIRC/1.2.4") DRI seems like it doesn't touch enough of the xc tree to warrant forking it the way I see you have an fd.o account yet? gah, in the backlog anholt: yes, but I only have access to the Mesa tree nuh-uh... ajax@pdx:~$ id sroland uid=1171(sroland) gid=100(users) groups=100(users),10001(dri),10039(mesa) sroland: try it out anholt: wait a sec. heh. so of course sf's down now... <-- fxkuehl has quit ("Verlassend") ... and back. Do you recall anyone working on stereo support except Andreas Elhiar? paproch: Not that I'm aware of. I'm currently working on that for radeon and r200. anholt: yes it works (when I finally got my cvs setup right ;-)). And what are the chances of integrating such work in dri tree? I'm asking becouse I don't know how much i have to car about compatibility. paproch: It depends. paproch: Ah. Well, that will hurt your chances. :) paproch: Like any large changes, they'd have to be reviewed by the other developers. idr: i see a mere 9 open bugs in the past 20 months, and three with your name on them. any comments on those? idr: Sure, I think that there will be no change in way driver works when stereo will be disabled. idr: do you have any idea how to do ARB_tex_env_crossbar on r200? I've looked at that texture combine stuff a bit, but I see no way how to make this extension work in a useful way if it has to work with 6 texture units. 5 would be ok, though... idr: the r200 really lacks a register :-( sroland: Yes, but it's tricky. idr: I think I' ll be able to post some patches next weekend. sroland: Basically, you have to reschedule the combine "instructions" and intelligently assign registers. sroland: I experimented with it a bit in python. :) ajax: I'll have to look at them. idr: but there are only 6 registers, so basically it is impossible to work in all cases. idr: even with rescheduling (since one texture environment might need more than 1 texture reference) sroland: Since you can only access 3 registers per instruction, it is almost impossible for 5 texture instructions to use all 6 texture values AND all the "previous" values. sroland: That's the trick. Every combine stage has to use PREVIOUS or you can eliminate (i.e., dead code removal) those previous combine stages. :) paproch: I'll keep an eye out for your patches. sroland: But yeah, it would have been nice if there were 1 or 2 extra registers for temporaries. hrm. need components. idr: I still don't see how it can be done. The combine stages can reference any texture they want, so if env1 refers tex 1,2,3, env2 refers 2,3,4, ... env6 refers 6,1,2 how do you reschedule that? sroland: In that case, you don't need env 1 or env 2. sroland: Since their result is unused, you don't need them. idr: ah I see. sroland: I'll send out my python code tomorrow. You can beat on it and see if you can find a case that fails. :) idr: sounds like complicated stuff... sroland: Without the test cases, it's only 178 lines of python code. idr: I'll try to beat it :-) sroland: That includes some code to do CSE. I want to be able to enable NV_texture_env_combine4 on R200 (if we can get permission from Nvidia). idr: CSE? common subexpression elimination sroland: common subexpression elimination sroland: Since each combine4 stage can be 2 stages on R200, you need to do some optimization to be more likely to keep it down to 8 instructions. idr: but it's not possible to always work (with 6 texture units), or is it? idr: kinda funny that even the TNT register combiner can do something the r200 almost can't - that quad-argument add is nasty ;-) sroland: So, if you have code that does env0 = t1 * t2 + t3 * t4, env1 = t1 * t2 + t5 * env0, you only have to calculate t1*t2 once. Store it in a temporary and re-use it. sroland: It can't *always* work with 6 TMUs, but 99% of the useful cases will. sroland: The trick it to make sure the code generator can handle all 99%. :) idr: in practice though most code using it maybe doesn't use more than 2 registers anyway (to make it run on a TNT). sroland: I am surprised that more companies didn't pick up on the (a*b)+/-(c*d) thing. It seems pretty obvious.