**** BEGIN LOGGING AT Mon Mar 18 15:54:40 2002 Mar 18 15:54:40 --- Topic for #dri-devel is DRI/DRM/Mesa driver development forum | DRI developmental Q&A meeting every Monday at 4:00pm EST (2100h UTC) | Not a technical support forum for end users, use #dri or #xfree86 instead please. Mar 18 15:54:40 --- Topic for #dri-devel set by ChanServ at Sun Feb 24 00:15:31 Mar 18 15:54:44 -ChanServ- [#dri-devel] Welcome to the DRI development channel. This forum is for the discussion of software development issues pertaining to the DRI project (http://dri.sf.net), including DRI/DRM/Mesa development issues. Weekly meetings are held at rotating times every Monday, and will be advertised in the channel topic. Please use #dri or #xfree86 instead if you're an end-user seeking technical support. Mar 18 15:56:36 --> andreas_s (~Andreas@pD902E2B3.dip0.t-ipconnect.de) has joined #dri-devel Mar 18 15:58:57 --> fragdance (fragdance@213.204.158.69) has joined #dri-devel Mar 18 15:59:18 --> idr (~idr@w-10n242.numaq.ibm.com) has joined #dri-devel Mar 18 15:59:27 Hi all, hope it hasn't started yet. Mar 18 16:00:35 --> AndyF (~andy@modem-174.pounder.dialup.pol.co.uk) has joined #dri-devel Mar 18 16:00:39 nope, just beginning to fill up Mar 18 16:01:29 Ok, good. Wasn't sure when 2100 UTC was Mar 18 16:01:36 --> alanh (~alanh@fairlite.demon.co.uk) has joined #dri-devel Mar 18 16:02:15 --> BrianP (~brian@brianp.phrog.org) has joined #dri-devel Mar 18 16:06:39 --> keithw (~keithw@213.78.88.160) has joined #dri-devel Mar 18 16:07:21 --> Cabud (jcdubacq@m94.net81-64-248.noos.fr) has joined #dri-devel Mar 18 16:08:47 hello? Mar 18 16:09:03 hi Mar 18 16:09:03 hi keith Mar 18 16:09:03 Brian: Is there any big differences between coding drivers for dri and Mesa? Mar 18 16:09:08 Hi Keith Mar 18 16:09:14 hello Mar 18 16:09:33 it's pretty different. The Mesa drivers basically just read/write pixels from/to the framebuffer while the DRI drivers issue hardware commands to render lines, triangles, etc. Mar 18 16:10:01 fragdance: Hi. But: All the dri drivers (in the dri cvs anyway) are also mesa drivers, so from that point of view you are writing a mesa driver. Mar 18 16:10:13 hello keith.. did you get the mail about the infinite loop problem ? Mar 18 16:10:28 Well, that's what I've done in the DX driver (making my own ChooseTriangle etc) Mar 18 16:10:28 keithw: I grabbed utah source a few minutes ago. Looks relatively straightforward to pinch their thrashing texture stuff... Mar 18 16:10:38 andreas_s: um.. I've been away for the weekend & kindof dropped everything. I'll look back. Mar 18 16:11:12 idr: did you get the texture files I sent ? dri_tmm.[ch] Mar 18 16:11:32 leahcim: neat. idr: are you still thinking about abstracting out texture management? Mar 18 16:11:48 keithw: i found the original article: http://www.theddrzone.com/news.asp?id=404 maybe its usful for us, too? Mar 18 16:12:17 alanh: I got them, but I haven't looked at them closely yet. Mar 18 16:12:38 --> bronaugh (bronaugh@h24-80-163-25.gv.shawcable.net) has joined #dri-devel Mar 18 16:12:45 idr: can you give us a brief on what your doing with texture management ? Mar 18 16:12:56 I guess this has started Mar 18 16:13:12 idr: it's one thing that the gamma driver is lacking. Mar 18 16:13:38 keithw, alanh: I don't have IBM legal approval to release or commit to anything at this time Mar 18 16:13:46 idr: crikey Mar 18 16:13:57 keithw, alanh: But, I'm working to abstract out all of the texture management code to one place. Mar 18 16:14:34 idr: any word on when you could release ? Mar 18 16:14:37 keithw, alanh: After that, I hope to be able to expand the interface (beyond just UpdateLRU) and add support for some "smarter" memory management policies. Mar 18 16:15:06 andreas_s: recent Linux kernel fixes the MWQ problem. Mar 18 16:15:48 alanh: Ah, the wheels of justice (and the IBM OpenSource Steering Committee) move very slowly. :( Basically, I don't know. Mar 18 16:15:51 davej: thanks.. what is "recent" ? 2.4.18 or 2.4.19pre-ac ;-) Mar 18 16:16:02 andreas_s: ~2.4.14 or so iirc Mar 18 16:16:27 idr: probably still deciding whether the meeting notes should be release or not? ;) Mar 18 16:17:34 davej: is it fixed on all chipsets or only a few? (sis745 ?) Mar 18 16:17:46 idr: can you at least do design discussions in the open (ie on dri-devel) Mar 18 16:17:46 andreas_s: VIA only afaik Mar 18 16:17:47 (including hybrid VIA/AMD chipsets) Mar 18 16:18:55 keithw: Right now I've been working to take the existing code (from radeon_texmem.c, mostly) and pulling it out, so there's not much design to discuss. Mar 18 16:19:50 keithw: Part 1.5 is to make another existing driver (I'm using MGA because I have that hardware) use the device-independent code. Mar 18 16:20:06 keithw: Hopfully by the time I'm done with that (not too much longer, I hope), I'll be able to release the code. Mar 18 16:20:14 btw, does agpgart hacking come under the charter of #dri-devel ? Mar 18 16:20:30 idr: fair enough. It's good to at least know what's going on. Mar 18 16:20:30 keithw: I would think then we'd create a new branch and start doing interesting work and having discussions. Mar 18 16:20:48 davej: sure, but without jeff here, we're all pretty clueless Mar 18 16:20:58 idr: Well I've been thinking along the lines of adding a radeonChooseHeap (not thought much there) and basically changing the SwapOut in Upload to select based on whether the current oldest texture was used in the last swapbuffers call... Mar 18 16:21:15 keithw: ah, cool. Mar 18 16:21:49 idr: It sounds like a pretty cumbersome process. Mar 18 16:22:22 leahcim: I've been kicking around some ideas like that too. But I don't think that a ChooseHeap mechanism (like the MGA driver) is that good of a sollution. Mar 18 16:22:33 keithw: It's especially bad in this case because of the various legal agreements related to being on the ARB. Mar 18 16:22:41 keith: BTw, do you have some working notes or something lying around with all the macros? Don't have to be anything fancy, but something to work from Mar 18 16:22:55 ? Mar 18 16:23:11 keithw: I think IBM has the most anal...er..."thorough" lawyers in the business. :) Mar 18 16:23:11 fragdance: which macros in particular? Mar 18 16:23:47 All of them :) I've been working with C++ and templates for some time, so macros make my head hurts (C++ and MSVC ide makes you lazy) Mar 18 16:24:05 idr: I figure it's down to performance, comparing swapping the overflow with using AGP for the overflow. Mar 18 16:24:19 idr: I wonder if you can get some sort of general exemption for small tasks - I'm thinking about maintainence of code you check in for one, but also just general helping out... Mar 18 16:24:40 keith: But I'm mainly interested in all the TAG(init) stuff going on. Mar 18 16:25:23 fragdance: there are heaps: most of them are to parameterize some code in a .h file - if you are looking at one or two in particular I can give a bit of an overview. Often there are notes at the head of the .h file, too. Mar 18 16:26:14 keith: I'll be better prepared next week so that I can be more specific Mar 18 16:26:32 fragdance: email works too Mar 18 16:26:57 fragdance: (usually...) Mar 18 16:27:32 keith: Yeah, but I generally like the possibility to talk 'face to face' better sometimes. Mar 18 16:28:41 Also, I'm trying to put together some docs about the internals of Mesa (using doxygen) so any info is welcome Mar 18 16:28:54 I didn't get very far with this 1024x768 problem I had :o/ Mar 18 16:29:03 fragdance: fair enough. It's a good point that those files need some more documentation. Mar 18 16:29:16 keithw: The Linux Technology Center here does have such an exception...but only for contributions to the Linux kernel. Mar 18 16:29:53 fragdance: have you seen the initial doxygen stuff in Mesa 4.1 (CVS trunk)? Mar 18 16:30:28 fragdance: have you looked at Jose's developer FAQ on the dri site, it's a good starting point. Mar 18 16:30:36 ? Mar 18 16:31:12 ldelgass: Got it on my desktop, will read through it soon. Also, I think all the dri drivers can help me Mar 18 16:32:33 leahcim: It's been a quiet week for me, too. I'm slowly pulling some of the sloppyness about the way random vertices are emitted to dma together, in the same work to try and get a better handle on the 7500 lockups. But for some reason going has been slow. Mar 18 16:32:33 BrianP: I've mostly used doxygen as a 'source navigator' Mar 18 16:33:01 BrianP: And I'm trying to keep the documentation I write down to a minimum :) Mar 18 16:33:05 fragdance: the macro stuff can be hard to understand, but the headers in the Mesa src have useful comments. Mar 18 16:33:57 Ok, for a first version of the doxy docs, is it enough just to take the existing comments and turn them into doxy comments? Mar 18 16:34:40 fragdance: In Mesa 4.1/doxy/ are scripts to generate html docs from the Mesa sources. Only some of the Mesa sources have been augmented with the doxygen comment style though. Mar 18 16:34:41 This would allow for a quick version, but quite useful nonetheless. Mar 18 16:34:41 I know, I did the scripts :) Mar 18 16:34:51 alanh: I was wondering, to check how my changes for bsd compatibility changed the actual code, how exactly did you produce the DRM code that is in, say, XFree86 4.2.0 release? Mar 18 16:35:06 fragdance: yes, converting existing comments to doxygen format would be nice. Mar 18 16:36:05 anholt: the code came straight from the bsd-2-0-0 branch Mar 18 16:36:57 but you ran the preprocessor on it or something, didn't you? Mar 18 16:37:35 --> roda (vedran@d-zg1-172.globalnet.hr) has joined #dri-devel Mar 18 16:38:04 anholt: yes, just a simple extractor that stripped out the __linux__ and __FreeBSD__ comments. Mar 18 16:38:39 still have it? (Looking for an easy way to do that again) Mar 18 16:38:51 anholt: yes. I'll email it to you. Mar 18 16:39:01 thanks. Mar 18 16:39:23 --> blork (~pacman@pixpat.austin.ibm.com) has joined #dri-devel Mar 18 16:40:25 keithw: Yeah, I've struggled for much time other than to grab bug reports off the list the last couple of weeks. The depth buffer stuff would be nice to solve in that regard Mar 18 16:42:37 leahcim: Oh yes. What was the cause of the texture-lod problems? That bug is probably on the trunk, too. Mar 18 16:42:55 leahcim: With that fix, the trunk will probably pass conform. Mar 18 16:43:23 leahcim: (tcl branch has some problems, notably with line stipple and specular lights) Mar 18 16:44:12 keithw: The state for negative values was writing over the register because you had = b instead of |= and the SCALE_TO_BYTE 256.0 / scale * x -1 overflowed on negative values Mar 18 16:44:55 hmmm Mar 18 16:45:41 I wonder where that code came from... Mar 18 16:46:26 keithw: Actually when I looked before I came to the conclusion that the per-texture state meant it wouldn't matter Mar 18 16:47:17 2400FPS on the trident driver with glxgears. Mar 18 16:47:17 albeit rendering no vertices :) Mar 18 16:47:32 alanh: The driver that doesn't do anything? That's fast! :) Mar 18 16:47:32 There's always a catch :P Mar 18 16:47:52 heh Mar 18 16:48:10 alanh: I can get 3000+ on the radeon, if I don't see about 85 frames less than I would by moving the xterm :o) Mar 18 16:48:13 leahcim: I only get 1900 Mar 18 16:48:13 leahcim: this is a 650 celeron laptop Mar 18 16:49:01 alan, leahcim: 1000 celeron/radeon 7500, but everything is rendered & visible Mar 18 16:49:53 alan, leahcim: I'm going to file a bug report... Mar 18 16:50:02 keithw: you'd only have to fix that.... :) Mar 18 16:50:19 keithw, alanh: I get about 950 odd duron 800/old radeon without cheating. Mar 18 16:50:59 leahcim: That's about what I got with old radeon. The trunk code is actually faster... Mar 18 16:51:00 Some questions about Mesa: elt, is that just an abbreviation for element, and is ac (array cache) just that, a cache for the different arrays (sorry for stupid questions, but want to be 100% sure) Mar 18 16:51:10 leahcim: Probably because it gets to use smaller vertices? Maybe it emits less state? Mar 18 16:51:46 keithw: I'll have to try. I thought it was quicker bar 1024x768 (which gets about 700) Mar 18 16:51:49 fragdance: Elt as in glArrayElement typically, used where there are indexed vertices. Mar 18 16:52:57 fragdance: ac: array_cache, see Mesa/src/array_cache/*.[ch] Mar 18 16:53:53 fragdance: It is really a layer that translates (and holds) arrays into the types mesa prefers: typically floats & ubytes. It does a similar service for the elements parameter of glDrawElements. Mar 18 16:54:06 fragdance: It does cache the good results. Mar 18 16:54:49 ok, thanx Mar 18 16:54:57 keithw: Is maos about storing these arrays in dma all the time? Mar 18 16:55:51 I have stability problems with radeon 7500 Mar 18 16:56:05 leahcim: Maos is about not building vertices but emitting arrays as arrays. So multipass rendering with cva (ala q3) gets a speedup on the second & subsequent passes as only the changed components are reemitted. Mar 18 16:56:40 leahcim: You could already use, eg, agp texture memory to keep the vertices for display lists in. Mar 18 16:57:13 leahcim: Which would be a huge speedup. (or on-card texture memory). Mar 18 16:57:22 keithw: Right. Is that where this NV_ vertex_range thing tuxracer uses comes into play? Or is that something else again? Mar 18 16:57:45 leahcim: Thinking about what should really happen here is one of the reasons I'm being slow with the 7500 stability issues: I want to make a deeper cut & enable some of this stuff. Mar 18 16:58:14 leahcim: NV_vertex_array_range exports a chunk of agp or card memory to the client & lets them put vertices in it. It's fast. Mar 18 16:59:13 leahcim: It's the way we should be using agp & card memory inside the driver. Rather than this archaic dma buffer thing... Mar 18 16:59:24 keithw: Right. tuxracer's problem is a) you can't lock arrays that don't start at 0. b) they use big arrays and probably c,d,e, and f which is what we've just discussed Mar 18 17:00:36 leahcim: You *can* lock arrays from n..m where 0<=n<=m<=n+MAX_LOCK_RANGE or whatever. Ie the locked region doesn't have to start at zero, and we support non-zero starts in mesa. Mar 18 17:01:42 keithw: hmm...I thought I'd stepped through here and saw if ctx->ArrayFirst == 0...else fallback_drawelements? Mar 18 17:02:08 leahcim: don't think so. I'll check Mar 18 17:03:08 leahcim: no, looks good to me Mar 18 17:03:18 leahcim: maybe you looked at 3.4? Mar 18 17:03:20 keithw: Hang on.... Mar 18 17:03:57 <-- Cabud has quit (Remote closed the connection) Mar 18 17:04:06 leahcim: Not that non-zero starts are well-excercised paths. But any bugs should be fairly straightforward. Mar 18 17:05:19 keithw: I think this is DrawElements rather than DrawArrays Mar 18 17:06:23 leahcim: Have a look at mesa/src/tnl/t_array_api.c -- it *should* work. Mar 18 17:06:40 --> jcdubacq (jcdubacq@m94.net81-64-248.noos.fr) has joined #dri-devel Mar 18 17:07:08 keithw: Aha, Yeah but iirc it's in the lock call? Mar 18 17:08:10 X just died Mar 18 17:08:12 --> aholtzma (~aholtzma@aholtzma.dsl.istop.com) has joined #dri-devel Mar 18 17:08:22 --> pokorny (~benutzer@rx4298.cip.uni-regensburg.de) has joined #dri-devel Mar 18 17:08:32 leahcim: You're right. Mar 18 17:08:58 keithw: So that's a bug / FIXME thing? I'll look at that after this texture thing Mar 18 17:09:03 leahcim: Another chance to wonder where that came from. Mar 18 17:09:18 sorry if i'm interrupting/bothering you guys, but I have a short question Mar 18 17:09:34 pokorny: Go ahead Mar 18 17:09:34 pokorny: fire Mar 18 17:09:57 i'm looking to buy a new video card, and i'm wondering if there is a chance to get dri-support for the radeon 8500 sometime in the future Mar 18 17:09:59 leahcim: yes, it's a fixme. Core mesa doesn't mind what happens there, the 'tnl' module might, but it should be fixed to cope. Mar 18 17:11:05 (I have to disappear for a minute) Mar 18 17:12:18 8500 is 3d less for the time being Mar 18 17:12:20 pokorny: Last I heard someone was working on it in their spare time. Mar 18 17:13:06 pokorny: If I were buying a card today for linux I'd get a 64mb 7500 Mar 18 17:13:29 leahcim: i guess then I'll just go for the 8500 (i heard this "rumour" too, i think it was in jose's faq) Mar 18 17:13:47 Radeon 7500 seems to work and there's anything nvidia is you want 3d now Mar 18 17:13:47 works quite well Mar 18 17:14:06 I get 1111 FPS for gears Mar 18 17:14:32 leahcim: yeah, i was thinking about a 7500, but 8500 is only ¤40 more... Mar 18 17:14:32 yes 8500 are on fire sale recently Mar 18 17:15:21 8500 has no 3d though and unknown who is doing what on it Mar 18 17:15:21 really? Here I'd pay about £75 for a 7500, £190 ish for a 8500... Mar 18 17:17:14 <-- jeff10 has quit ("Client Exiting") Mar 18 17:17:18 leahcim: that's both very high, i can get a 7500 for about 140 ¤ (about 90 pounds) and a 8500 for around 120 pounds Mar 18 17:17:42 actually: the 75 pounds is quite good, on second thought Mar 18 17:18:18 pokorny: you can use the radeon7500 today, but not the 8500 Mar 18 17:18:36 pokorny: at least not radeon8500s nice features Mar 18 17:18:53 leahcim: where are you in the uk? Mar 18 17:19:00 keithw: Bedfordshire Mar 18 17:19:13 andreas_s: yes, i understand that, and having a 8500 work with some basic dri would satisfy me Mar 18 17:19:17 leahcim: I'm in london. Everyone's in the uk... Mar 18 17:19:42 Except me, who left UK a year ago :) Mar 18 17:19:51 keithw: If you're catching the tube a lot I can see why you'd think that :o)) Mar 18 17:20:01 I've flown over the UK a few times...does that count? Mar 18 17:20:03 <-- jcdubacq has quit (Read error: 104 (Connection reset by peer)) Mar 18 17:20:08 pokorny: at some poing it will happen but if you want 3d now . 8500 isnt' an option Mar 18 17:21:04 terracon: i'm not desperately looking for instant support, i just don't want to buy a card that will never ever be supported Mar 18 17:21:23 pokorny: I bougth a 7500 some weeks ago. When thers a rudimentary driver for 8500 I buy a 8500 and if it works i will sell my 7500 Mar 18 17:21:23 idr: that's how I started - but there was a traffic jam getting back to heathrow so I just stayed... Mar 18 17:21:52 pokorny: who knows. It's like wishing for better vooodoo5 support Mar 18 17:22:00 terracon: ;-) (thank god i've got a voodoo3) Mar 18 17:22:06 although 8500 dri support is more likely to happen :) Mar 18 17:22:56 --> jcdubacq (jcdubacq@m94.net81-64-248.noos.fr) has joined #dri-devel Mar 18 17:23:12 they're about to refresh the r200 line so they've been slashing prices on the 8500 Mar 18 17:23:34 andreas_s: hmm, yeah, maybe that's another option, but i don't see the point in buying a 7500 when the 8500 is hardly more expensive (at least in Germany) Mar 18 17:23:59 My server crashed a second time. I am trying with no acceleration Mar 18 17:24:16 This time, I had to reboot Mar 18 17:24:29 pokorny: so I bought a 7500 to sell it if the 8500 is supported and than the 8500 is cheaper than today Mar 18 17:25:10 andreas_s: yeah, but i might as well keep my voodoo3 a little longer and wait some time maybe Mar 18 17:25:28 pokorny: all depends how much you rely on 3d Mar 18 17:25:49 terracon: good question, now as i'm through wolfenstein ;-) Mar 18 17:25:57 let's say 8500 takes 3 to 6 months to happen. Could you wait that long Mar 18 17:26:29 terracon: that would be fine with me, what i'm more worried about it seeing some support at all in the future Mar 18 17:28:34 pokorny: I can't answer that question because I don't know. If you want 3d get a 7500 or an nvidia board Mar 18 17:28:40 --> Tima (artem@adsl-63-205-128-227.dsl.lsan03.pacbell.net) has joined #dri-devel Mar 18 17:28:57 * BrianP is away: I'm busy Mar 18 17:28:58 pokorny: or buy an 8500 and play rtcw in "another os" Mar 18 17:29:07 terracon: ok, thanks, i guess i will still have to think about it Mar 18 17:29:12 pokorny: I have an 8500 so I'm in waiting mode Mar 18 17:29:53 pokorny: being 3d less sucks, I still have my original radeon 64 though Mar 18 17:30:11 andreas_s: that's what i partly did, but win version being 1.0, and linux 1.1, i couldn't open my linux-saves in win, so i finished it in linux Mar 18 17:30:37 terracon: yeah, i can keep my voodoo for some more time, its pci anyway Mar 18 17:31:09 pokorny: you could get 7500. voodoo would be painful now frame rate wise Mar 18 17:31:10 keithw: is it possible to put the radeon7500-kludge-around into the trunk or do you have another plan? Mar 18 17:31:39 terracon: you dont have to tell me that the voodoo3 is a bottle-neck ;-) Mar 18 17:32:04 to bad.. annex isnt here for news regarding the radeon8500 Mar 18 17:32:41 people even posting on rage3d.com today about 8500 linux support. Don't get too many of those but the people are getting wrestless Mar 18 17:32:44 <-- roda has quit (Read error: 104 (Connection reset by peer)) Mar 18 17:33:32 terracon: but 2D support for the 8500 is flawless isn't it? (including Xv) Mar 18 17:34:38 keithw: now that ATI is letting Gigabyte and Hercules and some others make boards. Do you think that would cause any problems or incompatabilities Mar 18 17:34:57 heh, Matrox has flawless 2D too ;) Mar 18 17:35:11 pokorny: 2d is ok. I wouldn't say flawless. Gatos does the Xv stuff. Mar 18 17:36:19 terracon: does the gatos code get merge to DRI, or might there be a situation where you have to decide between working Xv or working DRI Mar 18 17:36:24 terracon: hard to say. Mar 18 17:36:39 * jcdubacq goes to bed, but logs the text Mar 18 17:36:43 terracon: it would be good to get a better handle on the existing instabilities. Mar 18 17:36:58 hmm , ATI lists the 128 meg 8500. I wonder if this is a r200 or enhanced Mar 18 17:37:06 andreas_s: It's possible. I'll look into it. Mar 18 17:38:06 the only major instability for me is Tribes2. That continually gives the black screen of death Mar 18 17:39:34 terracon: Sure, but an app isn't an instability, if you know what I mean. It would be good to really understand why the kludge that's there fixes some problems. Or get a better idea of what causes the problems rather than just how to avoid them. Mar 18 17:40:38 terracon: This is one reason I think it's important to get off the odd little backwards-compatibility paths we're using at the moment and onto something that the ati drivers are using. Mar 18 17:40:38 keithw: true It's not a lockup per se. I just can't get any diesplay back and can't kill X or get to a console Mar 18 17:41:16 terracon: What I mean is sure, you get a lockup with that app, but what *actually* causes the lockup? I don't know. Mar 18 17:41:43 terracon: you might want to have a look at the program jslaunch, happened to be quite useful for me some times Mar 18 17:41:55 * BrianP is back (gone 00:13:02) Mar 18 17:41:58 keithw: I want to play with all the settings for that one but I don't want to keep loosing the display Mar 18 17:42:03 pokorny: I'll check that out Mar 18 17:42:27 terracon: Let me do this next bit of work before you try any serious testing. Mar 18 17:42:52 keithw: no problem. I really like the tcl branch so far though Mar 18 17:42:57 terracon: This is with a 7500? (Dumb q, but it sounded like you have an old radeon?) Mar 18 17:43:14 leahcim: original 64 vivo Mar 18 17:44:17 but than Tribes 2 has never really worked right. It's an nvidia game Mar 18 17:44:20 leahcim: Note that I saw the kludge lockup with the original radeon. I had to back off an optimization to get it to settle down. The 7500 is more sensitive. Mar 18 17:44:59 Tribes 2 worked on G400 OK Mar 18 17:47:06 keithw: Right, I didn't realise that. Mar 18 17:47:17 Well, I've got to go Mar 18 17:47:27 Nice talking to you all, see you Mar 18 17:47:36 <-- fragdance (fragdance@213.204.158.69) has left #dri-devel Mar 18 17:49:09 leahcim: it seems to be that radeon really likes to have some state between indexed primitives (at least with the old r128 compatibility packets) Mar 18 17:49:49 leahcim: the new packets actually seem to require 2 packets per primitive, so maybe that's what the card really likes. Mar 18 17:50:03 keithw: I keep hearing reference to "old R128 compatibility packets." What's the deal with that? Mar 18 17:50:08 keithw: davej told me that the Memory wait queue issue is alrady fixed on VIA-Chipsets in the Kernel (this was in the mail) Mar 18 17:50:19 leahcim: as you can see, we're into some pretty touchy-feely territory Mar 18 17:50:36 andreas_s: OK, that's one avenue we don't have to explore Mar 18 17:51:23 idr: It's just cause I can't remember their proper names: RADEON_CP_PACKET3_3D_RNDR_GEN_INDX_PRIM, actually Mar 18 17:51:25 keithw: lol yeah.. Mar 18 17:51:54 idr: but my bet is ati doesn't use or particularly care about them, so they may be a little iffy. Mar 18 17:52:23 keithw: If ATI doesn't use them, why does DRI? Mar 18 17:52:29 idr: Other packets require a MAOS packet in the middle to point to a new set of vertices Mar 18 17:52:45 idr: because kevin based the kernel module on the r128? Mar 18 17:52:49 keithw: Ok. :) Mar 18 17:53:04 idr: Also, there's nothing in the docs to say that using these packets is wrong. Mar 18 17:53:35 idr: and it's the easiest way to get a d3d-vertex driver up & running on radeon. Mar 18 17:54:10 idr: But, d3d vertices are a pretty crap path if you can do maos... Mar 18 17:54:48 idr: (except for the codegen-vtxfmt stuff, where vertices are nice after all) Mar 18 17:54:54 keithw: MAOS is? :) Forgive me lack of acronym knowledge. :) Mar 18 17:55:21 s/me/my/ Mar 18 17:55:25 multiple arrays of structures. It's more flexible than this, but it basically allows you to upload arrays rather than vertices Mar 18 17:55:43 keithw: Gottcha. Thanks. Mar 18 17:56:09 keithw: codegen/vtxfmt have you touched that / are touching it / intend to touch it? Mar 18 17:56:25 leahcim: touched what in particular? Mar 18 17:56:37 leahcim: I haven't been looking at it so much recently. Mar 18 17:56:49 leahcim: I'd like to get the array path looking better atm. Mar 18 17:57:03 <-- AndyF has quit ("Client Exiting") Mar 18 17:57:06 leahcim: And then get display lists onto card memory Mar 18 17:57:12 keithw: The filling out of it really, so it's more complete Mar 18 17:57:37 leahcim: I started something. It's pretty complex, but I can share what I've done. Mar 18 17:57:46 thanks everybody; see you Mar 18 17:57:46 <-- pokorny has quit ("Client Exiting") Mar 18 17:57:57 leahcim: Also the multiple primitive aspects of it tie into the packet rework in a couple of small ways Mar 18 17:58:29 leahcim: What would be good is two paths to emit vertex data: arrays and vtxfmt, and one piece of code to emit primitives Mar 18 17:58:53 --> AndyF (~andy@modem-174.kook.dialup.pol.co.uk) has joined #dri-devel Mar 18 17:59:44 keithw: Aha Mar 18 17:59:49 leahcim: The current radeon_tcl.c code does some good optimizations merging primitives & emitting elts for quads, loops, etc. Having the vtxfmt stuff hand over a bunch of vertices in agp space & a list of primitives to that code to emit elts and optimized (merged) primitives would be the way to go Mar 18 17:59:56 I gotta run, cya later. **** ENDING LOGGING AT Mon Mar 18 17:59:59 2002