--> sroland (~sroland@80-218-20-107.dclient.hispeed.ch) has joined #dri-devel
--> bobbyd (~rob@i-195-137-31-171.freedom2surf.net) has joined #dri-devel
<idr> Just to let you all know, I will be around for the meeting, but I'll probably be late.
--> brainsail (~rob@p83.129.182.140.tisdip.tiscali.de) has joined #dri-devel
--> anholt (~anholt@p58.n-nypop02.stsn.com) has joined #dri-devel
<ajax> anyone know where i could find the old pmesa project?
<ajax> ... tough crowd
--> ppareit (~ppareit@40-100.244.81.adsl.skynet.be) has joined #dri-devel
<ppareit> hello, I've recently installed XFree86/dri-common/dri-savage from the binary snapshots
<ppareit> hardware acceleration works great, but I've got a couple of problems:
<ppareit> when I first start the x server, it takes all the cpu and I am unable to use the keyboard (need to ssh from an other pc to kill X)
<ppareit> the second time I start the X server (after a kill) it works alraegth
<ppareit> also when running a 3D application, I can run it constantly, the first time
<ppareit> but when I run the same, or an other 3D app the second time, it locks up after some random amount of time
<ppareit> those are the problems I've had...
<ajax> yep, savage is unstable
--- Griffon26 is now known as GrifGone
<ajax> do you get any unusual messages in your X log or in dmesg?
<ppareit> ajax: no EE, just checked, all seems to go well
<-- brainsail has quit ("Leaving")
<ppareit> ajax: if you tell me what files I have to watch (with tail -f ...) I could force a lockup (by playing two games in a row), my major troble is not knowing what to watch for...
--> erdi (~erdi@host182.pao.digeo.com) has joined #dri-devel
<ajax> the X log and dmesg are it really
<ajax> unfortunately dmesg doesn't have a 'continuous' mode
<bobbyd> when does the meeting start?
<ppareit> ok, I'll start an other 3D program, I'll crash, I'll reboot, and I'll report back to you, so the file /var/log/XFree86.0.log, I should follow, this can be done over the ttyS0
<ajax> bobbyd: 36 minutes ago ;) apparently no one has anything to say
<bobbyd> oh
<-- bobbyd has quit (Remote closed the connection)
<erdi> Is allowing DRI user space code access to IO registers that can control the DMA engine consider secure?
<ajax> generally not
<idr> erdi: It depends on the card.  Cards where it isn't safe don't allow it.
<erdi> the Via unichrome chip supports system memory to framebuffer DMA bitblt, currently the DRI driver maps the IO registers to user space, that maybe a problem
--> jonz (~jonz@jonz.dspam) has joined #dri-devel
--> fxkuehl (felix@dialin-212-144-009-157.arcor-ip.net) has joined #dri-devel
<jonz> Hi...anyone know how I might go about making a call to radeon to re-detect S-Video (as opposed to rebooting) ?
<-- _prefect has quit (""I learned to code the hard way. The way the man who learnt the vibrator ws infact an electric pencil sharpener." -- Manic")
<-- erdi has quit ("Leaving")
<-- anholt has quit (Connection timed out)
--> ppareit_ (~ppareit@70-8.244.81.adsl.skynet.be) has joined #dri-devel
<ppareit_> hello ajax: I've followed the log, when it crashed, but nothing was displayed
<ajax> d'oh.
<ajax> any of the savage developers around?
<fxkuehl> ajax: I'm here
--> anholt (~anholt@p58.n-nypop02.stsn.com) has joined #dri-devel
<ppareit_> hello fxkuehl: I'm already very glad for the things that have been done to the savage
<ajax> ppareit here is having some trouble.  server crashes, lockups, etc.
<jonz> hey anholt, you wouldn't happen to know a way to get radeon to re-detect for an s-video (e.g. without rebooting) ?
<fxkuehl> sorry to hear that :-/, what exactly is going wrong?
<anholt> no clue
<ppareit_> fxkuehl: well, the lockup is like this:
<ppareit_> fxkuehl: when I run an 3D app, say a screensaver for the first time, there is no problem
--> paulo (~paulo@201.1.65.54) has joined #dri-devel
<ppareit_> fxkuehl: then starting the second time, there might be a problem
<rvv> jonz, s-video out you mean?
<ppareit_> fxkuehl: it could be that it runs perfect, for hours, or it could be that it locksup the machine after a short time
<jonz> yah
<fxkuehl> ppareit_: hmm, you're not talking about two 3d apps running at the same time, are you?
<jonz> to make it redetect (it does on winders) so that you don't have to reboot
<ppareit_> fxkuehl: absolutely not
<fxkuehl> ppareit_: can you still log in remotely when it's locked up?
<ppareit_> fxkuehl: yes, kind of, it funny, I can log in, but doing ps aux | grep X will lock it up harder, kind of
<rvv> jonz, IIRC the mplayer or gatos guys figured that the video out is completely disabled at boot if it doesn't detect a connection
<jonz> rvv: windows somehow detects when you plug it in though, is there any way to activate it?
<fxkuehl> ppareit_: weird, it shouldn't have any effect. Can you run top? Which application is on top?
<ppareit_> fxkuehl: when I get the crash, usaly X or fgfs
<ppareit_> fxkuehl: but don't concentrate on fgfs, I get it with any other 3D app, also I've never run two instances of 3D apps at the same time
<-- ppareit has quit (Read error: 110 (Connection timed out))
--- ppareit_ is now known as ppareit
<fxkuehl> ppareit: when it's stuck in the 3d app, i would be helpful if you could attach to it with a gdb and get a backtrace.
<fxkuehl> s/i/it
<ppareit> could try that, fgfs?
<fxkuehl> ppareit: sure.
<ppareit> fxkuehl: doesn''t fgfs needs to be compiled with debugging information for that?
<fxkuehl> ppareit: it'll probably be stuck in the 3D driver, and that has debugging information compiled in.
<ppareit> fxkuehl: ach, ok, thought it, kind of, so I'll run some 3D app, make sure I have top running, so I now the PID, and then what? gdb -flag nr_pid?
<rvv> jonz, I'd assume if it's documented it would already be implemented in mplayer and/or gatos driver
<fxkuehl> ppareit: run gdb without arguments. Then type "attach <pid>".
<jonz> rvv, perhaps some way to reset the card entirely?
<ppareit> fxkuehl: ok, I'll do, once I'm busy, I'll lock up and lose internet for a while, see you soon back
<-- ppareit has quit (Remote closed the connection)
<ajax> anyone have i830+ specs besides keithw?
<-- jonz (~jonz@jonz.dspam) has left #dri-devel ("Leaving")
--> ppareit (~ppareit@164-6.244.81.adsl.skynet.be) has joined #dri-devel
<ppareit> fxkuehl: http://users.skynet.be/ppareit/dri-savage-lockup <-- I think it worked to get a backtrace, see in the middle of the file for the string "(gdb) bt"
<fxkuehl> ppareit: got it. Looks like something lock-related. How was the CPU usage distributed (in top) among X and fgfs?
<-- anholt has quit ("Leaving")
<ppareit> fxkuehl: I did not dear to run top while I know it might have crashed, I tried that a previous time, but then it locked up a bit more, strage once something inside the kernel (dri is part of the kernel I suppose)  locks up
<ppareit> fxkuehl: when I would try to run top, I would not have been able to run gdb anymore
<ppareit> fxkuehl: but I want to try it out if you need to know
<sroland> something completely unrelated, would it be difficult to implement arb_vbo (for r200)?
<fxkuehl> ppareit: I've never heard of this kind of problem. Really weird. I suspect it's a chip lockup though.
<ppareit> fxkuehl: well, it is a kind of problematic situation right know, I don't think the combination motherboard and video card fit well together
<fxkuehl> ppareit: BTW, your line numbers don't quite match mine. How old is your driver source?
<ppareit> fxkuehl: less than a week
<ppareit> fxkuehl: 22 I think
<fxkuehl> ppareit: you could try different AGP speeds. maybe that helps.
<ppareit> fxkuehl: how would I do that, the card is inside a PCI slot, on a i810 mobo, set as secondary card
<fxkuehl> ppareit: use the agpmode option in XF86Config
<ajax> agpmode has an effect on PCI cards?
<ppareit> fxkuehl: ok, what value do you suggest?
<-- fab_ has quit (Read error: 110 (Connection timed out))
<fxkuehl> ppareit: oops, forget AGP, I plain overread "PCI".
<fxkuehl> ppareit: In fact, I didn't know the driver worked on PCI cards :-/
<ppareit> fxkuehl: well, you know now that it kind of works :-) at least the first time around
<fxkuehl> ppareit: well, it'll completely break when I start working on vertex DMA again.
<ppareit> fxkuehl: and after the work on DMA, will it start working afterwards again?
<fxkuehl> ppareit: I got a Pci Savage IX lying around here (thanks to Alex). I'll experiment with it when I have time, maybe in two months.
<ppareit> fxkuehl: my card is an savage4, might not make much difference
<ajax> fxkuehl: sort of unrelated, but is there any chance the Savage 2000 3d core is related to the old Virge engine?
<fxkuehl> ajax: I have no idea. Isn't the Savage2000 supposed to be the most advanced one?
<fxkuehl> ajax: besides, I don't know how the Virge worked either.
<ajax> i don't know the savage lineage, i just know the 2000 was the one we don't handle in the savage driver.
<ajax> there's a virge driver in utah-glx
<ajax> of course the virge sucked
<sroland> fxkuehl: I thought the savage2000 is supposed to be the most broken one ;-)
--> fab_ (~bellet@bellet.info) has joined #dri-devel
<fxkuehl> sroland: according to http://www.probo.com/timr/savage40.html it's the best one. ;-) I doubt it has anything to do with the old S3Virge.
<idr> sroland: In principle you could do VBOs just like on-card textures.  The problem would be with MapBuffer, etc.
<idr> sroland: That said, we could do "fake" VBOs that would work just like regular vertex arrays. :)
<sroland> idr: but that wouldn't do much for performance...
<sroland> idr: I _think_ it is a major reason why ut2k3/ut2k4 is so slow
<-- fxkuehl has quit ("Verlassend")
<sroland> idr: because it says so in the readme
<idr> sroland: Well, ut2k3 also uses DrawElements, which is hiddeously slow on all the TCL cards.  *That* would be a much easier problem to solve.
<sroland> idr: well, the quote in the readme is "See above. The game might run, BUT IT WILL BE VERY VERY VERY SLOW
<sroland>      WITHOUT AGP TRANSFERS. There is nothing to do about this. If we
<sroland>      can't pass vertex data over AGP, the fallback is slow. Very slow.
<idr> sroland: Fair enough.  They do push a lot of vertex data. :(
<idr> ajax: Is there really an accelerated GL driver for the Dreamcast?
<sroland> idr: (not exactly talking about that extension though, but I know it can use arb_vbo, or the nvidia hack (vertex_array_range) or similar ati extension)
<ajax> idr: yep.  http://gamedev.allusion.net/docs/kos/cvs/kgl_html/ for the docs, very similar to opengl
<ajax> kallistigl is GPL'd too i believe
<sroland> idr: what exactly is the problem with DrawElements?
<idr> ajax: Very, very interesting.
<ajax> yep.  being as that's a nearly-stock powervr chip...
<idr> sroland: IHVs tell app developers to pass data as GL_UNSIGNED_SHORT, but Mesa can only hand GL_UNSIGNED_INT.  On entry to DrawElements, Mesa converts the GL_UNSIGNED_SHORT data to GL_UNSIGNED_INT data.  Since the card *really* does prefer GL_UNSIGNED_SHORT, the driver converts it *back* when it uploads it to the card.
<idr> sroland: It should just short-circuit all that crap and send the raw GL_UNSIGNED_SHORT data to the card straight away.
<sroland> idr: ah THAT problem. I remember you've mentioned it before.
<idr> sroland: Yeah...it's one of my Mesa pet peeves. :)
<idr> ajax: Too bad PowerVR series 2 cards are almost impossible to find. :(
<ajax> yeah.  almost as rare as these rendition things.
<ajax> i thought there were a few kyro cards with powervr 2 chips
<idr> ajax: Probably more rare.  I've been watching for one on eBay for over a year and I haven't seen a single one. :(
<idr> ajax: AFAIK, the only Series 2 card was the "Neon 250".
<-- ppareit has quit ("using sirc version 2.211+KSIRC/1.3.9")
<idr> ajax: The kyro cards are series 3. :(
<sroland> idr: I'd rather have a series 5 card ;-)
<ajax> aaw.  sucks.  have the powervr chips undergone major generational changes the way the radeon has?
<idr> ajax: Basically, the PC card was sooooooo delayed because of the Dreamcast that it was irrelevent when it finally was released. :(
<idr> ajax: Dunno.
<sroland> idr: I'm still scratching my head about how to solve that texcoord submission. Doesn't seem easy :-(
<-- ludal has quit ("Download Gaim: http://gaim.sourceforge.net/")
<idr> sroland: Yeah, unfortunately I haven't had a chance to really think about it either. :(
<idr> sroland: However, I have managed to spend a little time working on my "old" new memory manager.  I *really* *really* want to have a demo for DDC.  That's gonna be tough, though. :(
<sroland> idr: a new memory manager would certainly be nice...
<idr> sroland: Yeah...it will make a "reasonable" implementation of VBO (and PBO) possible.  That will be *nice*.
<sroland> idr: would it be reasonable to flush current vertices and just change the vtxfmt if the app switches texcoord commands? Or does that happen too often?
<ajax> yes.  i was wondering what else we needed for pbuffer support
<idr> sroland: Hmm...that might work.  It would be a little tricky to do, though.  I don't think most apps *ever* change which TexCoord command they use in a given Begin / End pair.
<sroland> idr: it might be tricky, but I think it's more or less the only way this is going to work - analyzing texture matrix won't really help.
<sroland> idr: of course, could maybe optimize (i.e. if silly app changes from texcoord3f to texcoord2f, continue using 3 coords to save that vtxfmt change overhead)
<idr> sroland: Right.  You'd only change if the size grew.  That makes sense.
<idr> sroland: You might be able to do some analysis to determine which size to use as default.
<idr> sroland: So, if 1D textures are enabled default to TexCoord1f, if cubic or 3D textures are enabled default to TexCoord3f, etc.
<sroland> idr: well 1D textures don't really exist currently in the driver ;-)
<-- paulo has quit ("Leaving")
<sroland> idr: That still would not solve though the problem with mixed texgen/-nontexgen coordinates. But that can wait.
<idr> ajax: FYI, http://www.sharkyextreme.com/hardware/reviews/video/neon250/
--> anholt (~anholt@p58.n-nypop02.stsn.com) has joined #dri-devel
<-- anholt has quit ("now to see if my new xorg with composite works")
--> HEMI (~HEMI@12-221-70-126.client.insightBB.com) has joined #dri-devel
<HEMI> Question...I've got a FreeBSD/alpha machine with an ATI 9100Pro card. Since FreeBSD doesn't have DRI (well, the DRI builds, but there's no DRM) support on Alpha, I'm looking for an OS that does. Is DRI working properly on Linux/ALpha?
<MrCooper> yes
<HEMI> Ah, just found the dri.sourceforge.net page. Looks like it will. Nifty...Now, could I persuade someone to get DRI working under FreeBSD so I don't have to run Linux anywhere on my LAN? :)
<HEMI> anholt had been working on it for a bit, but he seems to have lost interest, even though I sent him an ALpha to test with.
<MrCooper> what little Alpha specific bits are needed might be deductible from the Linux code?
<HEMI> Is that something that could be done fairly easily? :/ I know I'm asking for a bit much...I had a small part in fixing the tdfx kernel module to work under FreeBSD/i386, but that was basically just fixing _ifdefs.
<HEMI> MrCooper: most likely, yes...What would be the best way to start?
<ajax> you'd need to check for endianness and word size assumptions.
<ajax> that's about it.
<MrCooper> ajax: Alpha is little endian, no problem there
<ajax> best way to start would be to build it and see if it works
<MrCooper> HEMI: does it break at build or run time?
<idr> HEMI: My guess is that, since it the R200 driver works on Alpha Linux and x86 FreeBSD, it would just amount to tweaking #ifdefs to get it compile.
<HEMI> Hrm...
<HEMI> MrCooper: run-time...Locks the machine up solid.
<HEMI> idr: that's what I'd guess as well. I'm just not much of a programmer. :) If it is just fixing _ifdefs, I may be able to handle that. haha
<HEMI> Having working hardware accel would be about the last thing needed to really make this thing run the way I'd like it to.
<HEMI> I remember the tdfx code being utterly convoluted. :/
<ajax> that's pretty true
<ajax> the DRM stuff is pretty clean these days though, most of the cards are very similar on the DRM side
<HEMI> That's what I hear. Maybe it was the dependance on glide that made tdfx so ugly...
<ajax> pretty much yeah
* ajax has been banging his head against tdfx for months
<HEMI> anholt kept talking about merging glide in to tdfx and just eliminating the dependancy, but I don't think he ever bothered.
* HEMI decides to plug his Alpha back in.
<ajax> i'm tempted to try that.
<ajax> what i'd rather have is a totally glideless driver
<HEMI> Well, yeah...But wouldn't you need at least some implementation of the GLide ABI to talk to the hardware?
<ajax> right.  we call that "OpenGL".
<ajax> API, you mean.
<ajax> glide is very similar to OpenGL from the programmer's perspective
<HEMI> Yeah, I understand that...So how would you talk to the card? Were there some assembly-language routines to do things, or was it all done in C?
<ajax> same way the other drivers do it
<ajax> same way glide does it now, for that matter
<ajax> just one less layer
<ajax> basically, map registers and card memory into the process' address space and write to them
<HEMI> Yeah...I'm not familiar with how video hardware really gets from point A to point B.
<ajax> most modern 3d cards have a sort of packet protocol that you use to talk to them
<ajax> the packet could say "put a vertex here" or "load this texture into vram" or "switch to this texture conbination mode" or whatever
<ajax> the card defines a register space where you can write these packets, like a FIFO
* HEMI nods.
<ajax> one of the packets is "okay, render everything i just told you about"
<ajax> at which point the GPU takes all the state information you just told it and converts it to pixels
<ajax> cycle repeats
<Stilgar> ajax: you're a mine of information. thx. :)
<HEMI> Ah, geesh...
<ajax> some cards (tdfx for example) have individual registers for all the variables, and a rather limited set of commands
* HEMI didn't expect that...The "sound" SRM command actually plays sound.
<ajax> others (like r300 i believe) have extremely complicated packet formats and relatively fewer registers.
<ajax> anyway, it's all mapped into the PCI memory space, so all the registers just look like locations in memory
<HEMI> I see.
<ajax> the trick, of course, is writing the right values to the right memory locations in the right order
<HEMI> Is this DRI project going to stick with XFree, or work with x.org as well?
<ajax> works with xorg already
<ajax> in fact Xorg shipped with DRI support
<HEMI> Nice...I figured it would *now*, since x.org is pretty much a snapshot of X 4.3 before the license change...But what about down the road?
<Stilgar> HEMI: just curious, what's your alpha ?
<Stilgar> HEMI: xorg is more like 4.4RC2 than 4.3
<ajax> down the road i think the developers will work on the X server they use most, and for most people that will probably be Xorg
<ajax> nothing preventing someone from maintaining support for xfree86, but it's certainly not on my todo list
<HEMI> Stilgar: PC164LX, 533MHz 21164A, 1G RAM, ATI 9100 128M DDR/DVI/VGA/S-video, SYM22902 U2W SCSI controller, SB ViBRA16 ISA sound card, Intel Pro/100+, all living in an Antec KS-280B case. It's a home-brewed box. I think the board originally came from an Aspen Systems Durango II workstation.
<Stilgar> lucky you....
<HEMI> Yeah, understandable. Seems like xorg is going to be the "more developed" one from here on out.