Here's today's log, if someone wants to post it on the site. I might be able to fill in some of the missing dates too, does someone have a list of the missing ones?
-- Leif Delgass http://www.retinalburn.net
**** BEGIN LOGGING AT Mon May 27 17:00:08 2002 May 27 17:00:08 --- Topic for #dri-devel is DRI/DRM/Mesa driver development forum | DRI developmental Q&A meeting every Monday at 4:00pm EST (2100h UTC) May 27 17:00:08 --- Topic for #dri-devel set by ChanServ at Tue May 14 22:55:01 May 27 17:01:25 --> jens (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:02:21 <ldelgass> hi jens May 27 17:02:35 <jens> hi ldelgass May 27 17:02:52 <ldelgass> I wonder if Linus will join us ;) May 27 17:03:24 <jens> it's been great to get his input on the mailing list. May 27 17:04:34 --> AndyF (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:05:10 <jens> it's a holiday here in the US, so I don't know how many people we'll get today. May 27 17:05:58 --> jrfonseca (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:06:04 <jrfonseca> Hi gang! May 27 17:06:08 <ldelgass> jrfonseca: hello May 27 17:06:36 <xorl> radeon-20020527-linux.i386.tar.bz2 (1493 KB) May 27 17:06:40 <xorl> is there anyway May 27 17:06:45 <xorl> to have that working in freebsd? May 27 17:07:33 --> fxkuehl ([EMAIL PROTECTED]) has joined #dri-devel May 27 17:07:52 <anholt> xorl: if that's the tcl driver, you would need a TCL DRM and compile bzflag for linux. May 27 17:08:06 <anholt> I had a tcl drm for bsd at one point, but it has rotted. May 27 17:08:18 <xorl> http://dri.sourceforge.net/ May 27 17:08:25 <xorl> Linux Intel x86 Packages May 27 17:08:29 <xorl> :) May 27 17:08:38 <anholt> of course, when you have a tcl drm for bsd, you might as well compile the tcl 3d driver and use that. May 27 17:08:45 <jens> anholt: how's OS templating? Any progress? May 27 17:09:05 <xorl> anholt, how can i compile tcl drm for bsd? May 27 17:09:05 <anholt> jens: well, I'm kind of waiting for a response from you guys. Is it a good plan? May 27 17:09:09 <xorl> where can i locate this May 27 17:09:37 <anholt> xorl: it's not written at this point. May 27 17:09:47 <jens> anholt: sorry, I thought we gave strong tentative...yes :-) May 27 17:09:50 <xorl> :(:( May 27 17:10:08 <xorl> anholt how long would it take you? May 27 17:10:24 <jens> They only tentative part was seeing if we can get complete isolation of OS parts from device specific parts. May 27 17:10:57 <anholt> A day? I've got the TCL code in almost-decent shape and I would have to check to see if the tcl drm has been updated in CVS since then. May 27 17:11:11 <anholt> jens: that'll take another two minutes. May 27 17:11:14 <leahcim> is this like tnl_dd/t_dd_dmatmp2.h type stuff in kernel? May 27 17:11:22 <xorl> anholt; would you do it for me? May 27 17:11:51 <anholt> jens: then the only "OS" part of it is the fact that you must use the given macros to keep os-independent as people continue working on the code. May 27 17:12:12 <xorl> Compiling...install.sh: 546: Syntax error: Bad fd number May 27 17:12:31 <anholt> xorl: when I get some time. I've been playing with making glideless 3dfx recently, and it's sooooo much more interesting than copy'n'pasting the DRM code around. May 27 17:12:50 <jrfonseca> jens: I've just caught up with your email. When you mentioned "the direct path could be obsoleted", I got the idea that you were suggesting model based on inderect rendering alone. May 27 17:13:28 <jens> anholt: there could be three phases... May 27 17:13:49 <jens> anholt: 1st) prototype with one driver, proof of concept May 27 17:14:16 <jens> anholt: 2nd) move existing drivers to new template technology May 27 17:14:30 <jens> 3rd) move active new development to new template technology May 27 17:15:08 <jens> anhost: does this addres your concern about "as people continue working on the code"? May 27 17:15:46 <anholt> jens: what would you want for a "proof of concept"? To me, the current BSD DRM is very, very close. May 27 17:15:51 <jens> jrfonseca: Over the long haul we could end up with an indirect only model...but I don't see that happening anytime soon.. May 27 17:16:02 <xorl> anholt; =) May 27 17:16:12 --> alanh (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:16:19 <anholt> jens: How about if I make a tarball of linux/drm/ and bsd/drm/ and shared/drm/ of what I think would be the almost-final result? May 27 17:17:13 <jrfonseca> jens: Ok. But my interpertation is a possible end result? May 27 17:17:14 --> Svartalf (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:17:18 <jens> anholt: that would be great. I'll help getting some people to seriously look at it. I think people will be motivivated when they realize that's how future DRM drivers might need to be written. May 27 17:17:19 <Svartalf> 'lo all! May 27 17:17:43 <jrfonseca> Svartalf: Hi Frank. May 27 17:17:47 <ldelgass> Svartalf: Hi there. May 27 17:17:58 <anholt> what's the status of getting tcl ready to merge to trunk? May 27 17:18:32 <alanh> anholt: Are you leaving OS dependencies still in the driver files ? May 27 17:18:41 <Svartalf> jens: Are we discussing the devel list discussion? May 27 17:19:00 <jens> jrfonseca: I'm not sure you'd really get down to 1 driver, ever. May 27 17:19:28 <jens> jrfonseca: even drivers that are predominately user space oriented still have a fair amount of resource management in the kernel. May 27 17:20:00 <jens> jrfonseca: also, the 3D portion may be well served to standalone from the 2D portion, even if they are coming from the same server. May 27 17:20:38 <jrfonseca> jens: Keith P. mentioned a residual kernel. But what seems more interesting is the idea of the OpenGL state machine on the X server, and not the client. Is this possible? May 27 17:20:38 <jens> Svartalf: Yes, some of it... May 27 17:21:02 <Svartalf> Cool. May 27 17:21:08 <anholt> alanh: both macros and ifdefs in the drm_*? Yes, I would prefer that, unless others are all against it. May 27 17:21:19 <xorl> anholt; if you worked really fast and hard May 27 17:21:29 <jens> jrfonseca: We have an opengl state machine in the server now. It's just SW rendering, though. May 27 17:21:29 <xorl> do you think you could complete the tcl? May 27 17:21:36 <alanh> anholt: that doesn't imply shared. May 27 17:21:58 <anholt> alanh: I think I'm confused on the question. May 27 17:22:12 <jrfonseca> jens: Yes. libGLcore. But would it be viable to have the drivers there? (The original idea was have X spawn clients for rendering..) May 27 17:22:12 <anholt> xorl: I really don't have the time right now. The main priority is this OS templating. Once that happens, TCL will be easy. Until then it means constant maintenance for me. May 27 17:22:17 <alanh> anholt: Any of the #ifdef __linux__ / #ifdef __FreeBSD__ needs to be moved out of the drm*.h files into OS specifc ones. May 27 17:22:35 <alanh> anholt: You don't want ifdef's in the shared directory. May 27 17:22:45 <-- xorl has quit (Remote closed the connection) May 27 17:22:51 <anholt> alanh: if so, then we will have to not share those files. May 27 17:23:05 <alanh> anholt: correct May 27 17:23:09 <jens> jrfonseca: that idea of spawning another thread (not clients) is to alievate the dispatch and not force 2D to serialize with 3D. May 27 17:23:09 <anholt> alanh: I would be disappointed, but I'll go with it. May 27 17:23:45 <alanh> anholt: it's going to be tricky with files like i810_dma.c that has both OS and HW dependencies. May 27 17:23:52 <jens> alanh: can you summerize where the ifdefs are a problem? May 27 17:24:15 <anholt> alanh: iirc I got the i810 cleaned up pretty decently. I'll have to take a look at it again. May 27 17:24:44 <alanh> anholt: you don't want ifdefs in a shared scheme, because they get completely out of hand. The more OS'es supported the wealth of code that could potentially be added. That doesn't imply shared. May 27 17:24:48 <jrfonseca> jens: Ok. that's different. So, do you think there would be an advantage in doing so, i.e., shared memory comm between the clients and the state machine? May 27 17:25:22 <alanh> jens: sorry that last one was for you. May 27 17:25:42 <jens> alanh: thanks May 27 17:26:33 <anholt> alanh: however, the majority of the code for some of these files is shared. Maybe a drm_context_osdep.h (for example) in the bsd/ and linux/ which is included from the shared file? May 27 17:26:53 <anholt> (I don't remember if drm_context.h is particularly independent or not) May 27 17:26:53 <jens> jrfonseca: I think the shared memory idea relates to optimizing the GL transport. Currently GLX over the wire is terrible for textures, images and large amounts of immediate mode vertices. May 27 17:27:38 <alanh> anholt: I know a lot of the code is shared. One example, which needs more abstraction is the linked list interface which differs greatly between OS'es. May 27 17:28:09 <alanh> anholt: that really should be moved into the drm_os_*.h files more completely. May 27 17:28:10 <anholt> alanh: I've thought a couple of times that we should just copy sys/queue.h in and be done with it :-) May 27 17:29:04 <jrfonseca> jens: But do you think that would be faster than the current model? (One thing that seems improved is that is much easier to achieve security that way, since the client doesn't actually send anything harmful). May 27 17:29:30 <jrfonseca> jens: Note: by current model, I mean the direct rendering. May 27 17:29:50 <alanh> anholt: Do you want me to get a branch created for some of the shared DRM code, so we can all bash on it rather than keep pulling from web pages and all being out of sync ? May 27 17:30:28 <jens> jrfonseca: I think it would be very unlikely that you could go faster with any optimized indirect rendering vs user space DMA direct; at least in the near future. May 27 17:31:09 <fxkuehl> jens, jrfonseca: How close would accelerated indirect rendering be to what Utah-GLX does? May 27 17:31:19 <anholt> alanh: I would think bsd-3-0-0-branch would be fine. I haven't done anything on it yet. May 27 17:31:30 <alanh> anholt: yep. that sounds fine. May 27 17:31:31 <anholt> alanh: could I get cvs access for working on that (or whichever) branch? May 27 17:31:44 <alanh> anholt: I don't see why not. May 27 17:32:03 <jrfonseca> jens: But look for e.g. to the case of the mach64, where the DMA buffers are insecure. If the buffers were created and maintained in the X server, we wouldn't need to care about that. May 27 17:32:11 <alanh> anholt: you'd need to email Brian or Keith (as they're admins) May 27 17:32:24 <jens> fxkuehl: Are you talking about the method of sending large buffers from 3D driver to X Server for dispatch? May 27 17:33:04 <anholt> alanh: cool. doing that. May 27 17:33:09 <jens> jrfonseca: I'd like for you to not have to care they are insecure in the 3D client side driver. No data copying, just get it to the card. May 27 17:33:25 <fxkuehl> jens: Oops, I'm not that much into the details. Just know that direct rendering was the big advantage of DRI over Utah. May 27 17:34:23 <jrfonseca> fxkuehl: No. In the Utah-GLX the client run as root - in other words - it pretty overrides both the kernel and the X server. That's very different of what we'r discussing here. May 27 17:35:27 <jens> jrfonseca: actually, what we're talking about here does have alot of those aspects, if you think about it. May 27 17:35:36 <jrfonseca> jens: How come? Of course that that's my primarily concern now, but security must be addressed in some point. May 27 17:35:43 <Svartalf> jrfonseca: I think he's saying that we may want to modify our assumptions... May 27 17:36:41 <jens> jrfonseca: We would have trusted user level processes that we don't need to add the overhead of security to. May 27 17:36:47 <jrfonseca> jens: So you're suggesting that we assume for now that the client is secure. (And that security must be addressed by user permissions, and so on..) Is it? May 27 17:37:03 <jens> jrfonseca: yes. May 27 17:37:24 <leahcim> jrfonseca: like a flag that says 'i've got nolisten tcp and the guy who can run exploit-dma.c' is stood in my bedroom and can take the machine anyway May 27 17:37:27 <jrfonseca> jens: And in the meanwhile, we also work on the indirect rendering for the other cases too... mmm May 27 17:37:48 <terracon> well how do the nvidia drivers do it. Like utah? They're certainly not slow May 27 17:38:14 <jens> jrfonseca: otherwise it *very* difficult to compete with closed source drivers that do what they want. May 27 17:38:39 <jens> terracon: any way they want...security thru obscurity. May 27 17:38:40 --> svu (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:39:18 <jrfonseca> jens: I see... I get somehow the feeling that we're putting down a flag... but it can be that the indirect rendering enhancements yeild a good surprise... May 27 17:40:07 <jens> terracon: My comment is not aimed directly at NVidia. I've never seen their more recent docs. However, most of the chipsets are designed for great user space DMA performance...but they have security holes. May 27 17:40:58 <jens> jrfonseca: indirect rendering could turn out great, we'll see. Putting down a flag? I don't understand. May 27 17:41:06 <Svartalf> jrfonseca: I've been thinking that the indirect mode stuff may work WELL for some of these chipsets. May 27 17:41:20 <Svartalf> jens: He's meaning that we're not implicitly secure always. May 27 17:41:39 <Svartalf> I've been torn over that as well as a bunch of other things. May 27 17:42:11 <Svartalf> I'd love to come out with something that's totally rock-solid secure but is as fast as the Windows counterparts or faster. May 27 17:42:49 <jens> Svartalf: then you'll need to do the hardware design yourself :-) May 27 17:42:52 <Svartalf> But, I'm having difficulties getting there with the Mach64 (We all have) and the Trident CyberBlade (yep, I do happen to have some info there as welll..) May 27 17:43:04 <jrfonseca> jens: Putting down the flag, in the meaning that we're tradding security for speed. The most eligeble apps for OpenGL are games (usually closed source), if people need to run as root to get super-duper speed (and they will), it's jeopordizing the security of the system. May 27 17:43:12 <alanh> Svartalf: already started the CyberBladeXP driver. May 27 17:43:22 <Svartalf> jens: Don't tempt me. I've toyed with the idea of something like that- it's just I don't have the $$$ to do the VLSI work. :-> May 27 17:43:43 <terracon> I don't think people care. As long as they get uber fast fps May 27 17:44:16 <leahcim> jrfonseca: yeah but netfilter doesn't block packets, it lets me choose what I do. Deciding that q3 is trustworthy has loads more implications than it uses 3d and it's policy, imho May 27 17:44:18 <terracon> people have put up with the crashes and instablilty of Nvidia Linux for some time and they won't even consider DRI as an option. WHy? fps on nvidia is good May 27 17:44:22 <jens> Svartalf: seriously, if one vendor had a fast chipset w/ a secure and open source driver; then others might follow. Unfortunately, that hasn't happend, yet. May 27 17:44:51 <Svartalf> alanh: Not yet. I was going to help out for a little while longer on the Mach64 (I like to TRY to complete something I started.) before going on that one. It's going to be interesting since the architechture is...different. It'd almost be better as an accelerated indirect case. May 27 17:45:12 <alanh> Svartalf: no - i meant I've already started it. glxgears is already working. May 27 17:45:23 --> keithw (~[EMAIL PROTECTED]) has joined #dri-devel May 27 17:45:33 <jens> Hi Keith! May 27 17:45:37 <jrfonseca> jens: But I agree that is the best course of action: by assuming that the clients are safe, then the 3d drivers have the same expectation from the X server as of a client. So the code can be reused in both places. And that's quite important. May 27 17:45:40 <alanh> Hey Keith May 27 17:45:51 <keithw> Hi. Just back from dinner/the pub... May 27 17:45:51 <Svartalf> alanh: WOW! (Talk about saving me time... :-) Which CVS branch is it in so I can try it out on my laptop? May 27 17:46:20 <alanh> Svartalf: trident-0-0-1-branch, but that doesn't have all my code yet. May 27 17:46:24 <jens> jrfonseca: sharing the 3D driver for both direct and indirect is a *very* good thing. May 27 17:47:28 <alanh> Svartalf: is yours an XP or just the i7/i1 ? May 27 17:47:39 <Svartalf> alanh: Ah. Can't wait to help out w/testing, etc. on that. (It'd also give impetus to a hacking project I've got- I-Openers use the Cyberblade.) May 27 17:47:55 <Svartalf> alanh: i1 in both cases May 27 17:48:08 <alanh> Svartalf: then forget that branch - it's XP only. May 27 17:48:33 <Svartalf> alanh: Got it. How different is the XP from the original? (Perhaps I could work on that functionality...) May 27 17:48:40 <alanh> Svartalf: very. May 27 17:49:01 <alanh> Svartalf: but go ahead for the i1. May 27 17:50:09 <jrfonseca> jens: And when we reach that point we can access how do the both approachs compare (after adding some shared memory to the client communication). May 27 17:50:15 <alanh> keithw: which pub ? May 27 17:50:24 <jens> jrfonseca: just thought of one thing, you shouldn't plan on throwing security out just, yet. It would take a while for a new policy and the indirect functionality to get going. You'll still need to focus on security in the short term for your current driver. May 27 17:50:35 <Svartalf> alanh: Well, that stinks... :-) Guess I do have to do some work, then. There's a LOT of people that have those chips and while they're not fast by any stretch of the imagination, there's no reason to NOT give them support. As it stands, I've got an app into Trident's developer program that I should hear back from them on shortly. I was going to get the older chips supported and then step up to their new ones which rumor has are actually May 27 17:50:35 <Svartalf> quite nice (for a "cheap" part.) May 27 17:51:07 <jens> jrfonseca: yup! May 27 17:51:15 <alanh> Svartalf: that's why I'm starting with the XP. It's the latest in-production chip. May 27 17:51:16 <terracon> don't the Wal-Mart machines that come without the OS have the Trident chip in them May 27 17:52:15 <alanh> Svartalf: then I was going to work back.... May 27 17:53:03 <jrfonseca> jens: Well, should I do direct DMA from user space or really enforce secure buffers (by copying, or whatever)? May 27 17:53:17 <Svartalf> terracon: I think so. Some laptops come with them too. It's for that reason I was wanting to work on them. (Of course, you can ask Leif and Jose about my spare time problems... It comes and goes proportionate to how well I'm getting paid by my so-called employer.... :-) May 27 17:53:33 <jrfonseca> jens: The second one will give a lot of work. If's not for long, I'd rather not doing it at all... May 27 17:53:50 <jens> jrfonseca: really enforce secure buffers. May 27 17:55:11 <terracon> Svartalf: I'm just checking the wal-mart page and they don't list the video card but I'm pretty sure I read that it's Trident on them May 27 17:55:21 <Svartalf> terracon: They May 27 17:55:34 <jens> jrfonseca: the indirect rendering modules required are at least 6 engineering months of work. We have no one lined up to sponser this type of work. This is where I would like to see things move, but don't expect to be running under a released distro with this type of support for at least a year or two. May 27 17:55:36 <terracon> # Up to 64MB video accelerator, integrated May 27 17:55:42 <alanh> terracon: There are many many many different trident chips. May 27 17:55:43 <jrfonseca> jens: mmm.. ok. but in that case I vote for a secure-and-low-performance just for to go into a X release, as there's really not much point to figure out the most effective way to do it securely,and then erase that after some months. May 27 17:56:00 <alanh> terracon: none of them support 64Mb of memory. May 27 17:56:02 <jens> jrfonseca: or years... May 27 17:56:05 <keithw> alanh: (sorry, reading email) The london scotia bar, which is directly opposite our house... May 27 17:56:12 <terracon> http://www.walmart.com/catalog/product.gsp?product_id=1731320&cat=41937&type=19&dept=3944&path=0%3A3944%3A3951%3A41937 May 27 17:56:14 <alanh> keithw: nice. May 27 17:56:27 <terracon> pretty cheap for a 2GHz May 27 17:56:28 <Svartalf> alanh: Are they capped at 32Mb, even with UMA? May 27 17:56:32 <jrfonseca> jens: I'd rather invest my time in making those years becoming months. May 27 17:57:00 <alanh> Svartalf: I believe so. In fact pre-XP I think you'll struggle for anything bigger than 16. May 27 17:57:15 <Svartalf> keithw: Nice. May 27 17:57:24 <jens> jrfonseca: that's reasonable, but let's get our ducks lined up with the kernel teams before we jump into something this big. May 27 17:57:41 <keithw> jens, jrfonseca: And within dri-devel -- I'm not really convinced at this point. May 27 17:57:57 <keithw> jens, jrfonseca: Though I'd like to be... May 27 17:58:14 <jens> keithw: share your concerns. May 27 17:58:32 <Svartalf> keithw: Yes, we'd like to hear them. May 27 17:59:06 <keithw> jens: security, of course. I came late into the chat, so I don't know what's been said already. May 27 17:59:29 <keithw> jens: the games people play are network attached, subject to exploits, etc. May 27 17:59:39 <jrfonseca> jens: Oh sure. Mach64 is still some work to do: besides DMA, vertex buffers, efficient AGP, XAA enable, VT switch, I also want to do the necessary changes to have screens in AGP memory (4MB on this laptop...) May 27 17:59:53 <keithw> jens: but we're going to give them priviledged access to hardware? May 27 18:00:41 <keithw> jens: Oh yes, and they're closed source too. May 27 18:00:54 <jrfonseca> keithw: That's my concern too. May 27 18:01:00 <jens> keithw: but these aren't servers. These are single user boxes. You're concerned with data coming in on the wire being exploited by binary only games? May 27 18:01:17 <keithw> jens: There have been q3 client exploits. May 27 18:01:35 <keithw> jens: (I believe) May 27 18:01:56 <keithw> jens: Clients can have buffer overflows too. May 27 18:01:57 <jens> keithw: how are they diferent than exploits that can be done at root level install time? May 27 18:02:03 <jrfonseca> jens: yep. They just need to make a whorm for a widely used game and a widely used card. Then it's DRI on the security bulletins... May 27 18:02:42 <keithw> jens: they don't come from a "trusted" source - they just float down the wire while you're playing May 27 18:03:00 <Svartalf> jrfonseca: Problem is, you're not going to prevent that easily with any of these cards. I'm not saying to not secure things- just asking at what point is it diminishing returns. May 27 18:03:31 <keithw> Svartalf: You can't prevent the client getting taken over, but you can prevent the corrupted client from grabbing root via the dri. May 27 18:04:11 <Svartalf> keithw: Can you? If you're corrupting stack, anything could be done. May 27 18:04:12 <jrfonseca> The chances of someone running a widely used game with a widely used card, and the user runs a root (since he obviously want's to get the best of it's expensive card performance) are really high. May 27 18:04:19 <svu> jrfonseca: Sorry fo interrupting but please NO! As an ordinary user/gamer/DRI tester, I pray: please NO. Give us FPSs and then tighten security. For 3D, I am sure waste majority of users would choose speed over security (definitely, having both would be perfect but if we have to choose one...). I really believe properly tuned firewalls and _other_ security measures can make LAN games acceptably secure. May 27 18:04:38 <keithw> Svartalf: That's not true - the stack isn't special in any way. Root *isI. May 27 18:04:42 <keithw> *is* May 27 18:04:43 <leahcim> Svartalf: you need a root exploit to get from the user running the game May 27 18:05:50 <Svartalf> keithw: Well, we're reasonably sure we can keep a root exploit out of the stream with the Mach64, but we're not so sure about DoS attacks hanging the console on the box. May 27 18:06:01 <jens> leahcim: those are the insecure commands that are in the 3D buffers. May 27 18:06:08 <jrfonseca> svu: Sorry, but I don't see things as simple as that. Everbody should concern with security, otherwise cards will be designed to be run with priveledges. May 27 18:06:21 <terracon> svu: that is true but there's the drm kernel portion and the kernel people wont' accept anything half ass so to speak so it has to be done right May 27 18:06:28 <leahcim> jens: Yeah, I was just pointing out that stack overflow itself just means all your personal data is gone, not root ;o) May 27 18:06:49 <jens> leahcim: oh rihgt. May 27 18:07:30 <keithw> Svartalf: You probably can't stop people *crashing* the box - even sequences of perfectly legal commands can crash graphics cards - they're all flaky one way or another. May 27 18:07:54 <jrfonseca> keithw: And what do you think about having the GL drivers on the X server context, and the client comm be carried via shared mem? May 27 18:08:10 <Svartalf> keithw: Ok, then, is that the line in the sand? Do your level best to keep them from crashing but keep a root exploit impossible at all costs? May 27 18:09:06 <keithw> jrfonseca: I think that sounds a lot like the 'cmd_buffer' ioctl in the tcl radeon driver. It doesn't really matter if the kernel or the X server handles the insecure commands - it's pretty much equivalent May 27 18:10:26 <keithw> jrfonseca: One thing I'd consider is transforming the 'cmd_buffer' ioctl so that it really understood native hardware commands, and did verification on them but otherwise passed them on unchanged to hardware. May 27 18:10:51 <terracon> keithw: that page flipping was good. I played Tribes2 for quite awhile and no lockups May 27 18:10:58 <keithw> jrfonseca: Then it would be relatively easy to switch between 'secure' and 'insecure' modes of operation . May 27 18:11:04 <jrfonseca> keithw: I don't know much about 'cmd_buffer', but I don't see how that can be resemblant. By having the drivers in the X process, the buffers would be generated on a trusted environment so, cards such as mach64, didn't have to worry about insecure DMA buffers. May 27 18:11:18 <keithw> terracon: It has correctness problems, no lockups. May 27 18:11:29 <jens> keithw: nieve question...if we trust the source, why can't we trust the source to filter out network attacks based on it nowing it's own protocol? May 27 18:11:32 <leahcim> what about user mode linux + something so the only real memory you have is mmap() and agp/dma - that might be a model for debugging drm if nothing else May 27 18:12:03 <keithw> jens: I don't think we should have to trust either. May 27 18:12:47 <keithw> leahcim: You could debug drm correctness that way if you simulated the hardware... May 27 18:13:07 <keithw> leahcim: It might be reasonably easy to build simulators, but you wouldn't know about the bugs... May 27 18:13:19 <keithw> leahcim: It's kindof interesting... May 27 18:13:20 <jens> keithw: if se do the "secure"/"insecure" switch on 'cmd_buffer', can we execute insecure buffer from user space? May 27 18:13:59 <svu> jfonseca: Well, but taking that you team have unlimited performance and can develop both secure and fastest versions by tomorrow morning - would you ship both with XFree (with appropriate explanations and warnings) - and leave the choice to a user? Or will you never give people maxfps if you have a chance of exploit? May 27 18:14:03 <jrfonseca> jens: It's not just network attacks. Since they are closed source games, it could be trojans. Just root-kits. May 27 18:14:06 <keithw> jens: Kindof, in 'insecure' mode, the client would emit to agp memory instead of cached, and the kernel would just fire that as a buffer. May 27 18:14:40 <keithw> svu: that's what we're discussing. May 27 18:14:42 <jens> keithw: hmmmm...so we still have system call overhead, but not data copying, etc.... May 27 18:15:08 <keithw> jens: And only one system call per 8k/16k/1024k/whatever of commands. May 27 18:15:41 <jens> keithw: tho Linus was pushing for small buffers from a cache perspective. May 27 18:16:14 <keithw> jens: But cache doesn't come into it in the agp case - only when you're copying data for security. May 27 18:16:40 <jrfonseca> jens: But Linus suggestion only matters for cards such as mach64, which will have to read/copy the buffers (to be secure). Other cards just dispatch the buffers to the BUS. May 27 18:16:41 <jens> keithw: so would you consider the AGP case secure? May 27 18:16:46 <keithw> jens: In anycase, one syscall per 8k of commands is vanishingly small. May 27 18:16:55 <keithw> jens: No, that's the insecure option. May 27 18:17:21 <jens> jens: if we have an insecure option, why not go all the way? To avoid writting indirect support? May 27 18:17:27 <keithw> jrfonseca: Well, even the radeon generates quite abit of insecure traffic. May 27 18:17:39 <keithw> jens: talking to yourself? May 27 18:17:47 <jens> :-) May 27 18:17:56 <keithw> jens: all the way to where? May 27 18:17:57 <jens> that's for you, keith May 27 18:18:27 <jens> keithw: a user space ring that's being synchornously drained by the HW. May 27 18:18:56 <jrfonseca> keithw: Yes. That's why the opengl state machine on the X server seemed so interesting to me. After all the OpenGL protocol tries to keep most stuff on the state already, so there would be less bandwidth from the client. May 27 18:19:01 <keithw> terracon: The problems are obvious if you have an app like isosurf that doesn't render continuously & then try moving it's window, preferably with a window manager that does 'outline' type moves (rather than opaque ones) May 27 18:19:20 <keithw> jens: Because the hardware doesn't support it? May 27 18:20:13 <keithw> jens: But if it did, I might still do it this way for ease of coding both paths. May 27 18:20:22 <jens> keithw: the Radeon doesn't support an AGP ring where the driver is filling one end and the HW is draining the other? May 27 18:20:53 <keithw> keithw: Not per-context - I suppose the 'main' ring could be shared between the X server and client. May 27 18:21:08 <keithw> jens: May 27 18:21:19 <keithw> jens: This is all very 'utah-glx'. May 27 18:21:19 <MrCooper> keithw: yep, see ati-5-0-[01] branches May 27 18:21:57 <MrCooper> keithw: well, mostly those share the ring between the kernel and X server May 27 18:22:03 <jens> keithw: I'm just trying to get at the modes of data flow that appear most natural to hardware designers... May 27 18:22:07 <keithw> terracon: You can turn it on with an XF86config option atm. May 27 18:22:33 <-- svu has quit ("[x]chat") May 27 18:22:45 <keithw> MrCooper: That's how it should work now, I think. That's how I did the i810 & it works fine. The radeon driver issues all these bogus ioctls when it could just hit the ring. May 27 18:23:30 <MrCooper> but of course, according to Linus, the ioctls don't matter :) May 27 18:23:33 --> svu (~[EMAIL PROTECTED]) has joined #dri-devel May 27 18:23:54 <keithw> jens: That's reasonable, but bear in mind we'd still want to do the 'batch buffer' thing - that's a part of the hardware for a reason. May 27 18:24:07 <keithw> jens: Grabbing the lock is probably as expensive as a syscall May 27 18:24:19 <keithw> jens: (Although at the moment we have to do both...) May 27 18:24:37 <keithw> jens: It would be necessary to grab the lock before touching a shared ring. May 27 18:24:54 <jens> keithw: agreed. we need to streamline context switches as well. luckily there aren't a mainline performance case when we running a single 3d context. May 27 18:24:56 <-- svu has quit (Client Quit) May 27 18:25:10 <keithw> jens: I mean the uncontended case. May 27 18:25:16 <jens> keithw: I've got some ideas about using page faults... May 27 18:25:38 <keithw> jens: You're thinking about a big redesign. May 27 18:25:51 <jens> anholt, alanh: sorry, I shouldn't scare you with words like page faults :-/ May 27 18:26:06 <MrCooper> jens: BTW IME drmCommand seems to have reduced ioctl overhead significantly :) May 27 18:26:11 <alanh> alanh: I'm still here.. not scared at all. May 27 18:26:38 <jens> alanh: can we make page faulting portable across OS's? May 27 18:26:50 <alanh> jens: I'm sure we can abstract it. May 27 18:27:04 <keithw> alanh, jens: Yes. May 27 18:27:11 <MrCooper> jens: would page faults be better than grabbing the lock? May 27 18:27:42 <keithw> MrCooper: The cost of setting them up would be larger, but only occur on context switches, which hopefully are rare. May 27 18:28:00 <alanh> jens: I'm a little concerned about redesigning too much and leaving unmaintained drivers behind. (like the SiS driver). May 27 18:28:06 <leahcim> is the ring just contiguous, you couldn't just have a q and make the locking adding a q entry, or is there no way to make it skip the q stuff? May 27 18:28:14 <keithw> jens: This is also very 'utah-glx' -- a similar scheme was used inside the X server there. May 27 18:28:40 <jens> keithw: you are right, these is a large redisgn. What I'm really looking for is headroom. If we can soften user space 3D driver requirements, we give ourselves a lot of headroom. May 27 18:28:59 <keithw> jens: I'd like to see anything like this coexist with the old stuff. May 27 18:29:10 <jens> keithw: absolutely. May 27 18:29:20 <keithw> jens: This is very hardware specific in terms of whether it would even work at all, I think. May 27 18:29:33 <keithw> jens: It also presupposes a favorable outcome on security. May 27 18:29:35 <jens> keithw: that's usually the case with all 3D drivers. May 27 18:30:12 <keithw> jens: Re specificity - that's ok, but I don't want to have to bring all the old drivers through to some new scheme. May 27 18:30:16 <jens> keithw: right. I mentioned this earlier. We need to continue to write secure drivers. This is all speculative. May 27 18:31:29 <jens> MrCooper: I'm surprised drmCommand is noticably faster. Are you sure you didn't get some other source updates? May 27 18:32:15 <MrCooper> jens: IIRC I tested right before and after the drmCommand changes May 27 18:32:38 <keithw> MrCooper: How are you measuring this? May 27 18:32:45 <MrCooper> x11perf :) May 27 18:32:58 <jens> MrCooper: that's 2d. May 27 18:33:11 <jens> oh :) May 27 18:33:16 <MrCooper> heh May 27 18:33:20 <jens> cut it out! May 27 18:33:22 <keithw> wtf? May 27 18:33:26 <jens> :^) May 27 18:33:26 <alanh> ?? May 27 18:33:39 <jens> MrCooper was pulling my chain. May 27 18:33:54 <MrCooper> huh? May 27 18:34:13 <MrCooper> I bet everyone's confused now :) May 27 18:34:14 <anholt> jens: page faults? I'm sure it's doable, it's just something for me to learn how to do. May 27 18:34:18 <jrfonseca> yep May 27 18:34:35 <jens> I gotta run guys. I'm glad we had a holiday today. I've been to booked to make these mtgs. It was fun! May 27 18:34:51 <alanh> it's late in the UK too. May 27 18:34:57 <keithw> yep. May 27 18:35:01 <-- jens has quit ("Client Exiting") May 27 18:35:01 <keithw> Night all. May 27 18:35:02 <jrfonseca> jens: cya. it was a nice meeting indeed! May 27 18:35:07 <-- keithw has quit ("using sirc version 2.211+KSIRC/1.1") May 27 18:35:09 <jrfonseca> niight May 27 18:35:22 <-- alanh has quit ("alanh has no reason") May 27 18:35:33 <jrfonseca> Is some one making a log out of this? May 27 18:36:04 <ldelgass> jrfonseca: I have logging on. May 27 18:36:19 <jrfonseca> ldelgass: good. May 27 18:36:33 <jrfonseca> ldelgass: So what do you think of all this? May 27 18:37:10 <MrCooper> ldelgass: I could save the xchat buffer but a real log is probably better May 27 18:37:36 <ldelgass> jrfonseca: I'm mostly concerned with finishing with the path we're on and then adding in the security. May 27 18:37:43 <jrfonseca> ldelgass: I know that we have our hands full for quite some while, but the security issue on Mach64 is always a concern.. May 27 18:38:06 <ldelgass> jrfonseca: I'm going to try doing blits without register commands, so we could avoid copying texture buffers. May 27 18:39:08 <jrfonseca> ldelgass: I'm going be working to deliver my paper up to the last minute... :-/ May 27 18:39:21 --> AndyF_ (~[EMAIL PROTECTED]) has joined #dri-devel May 27 18:39:27 <-- leahcim has quit ("[x]chat") May 27 18:39:55 <ldelgass> jrfonseca: I'm going to try implementing your idea and emit descriptors to the ring as we go. I'll need that to test the blits, since the descriptors would be different. May 27 18:40:53 <ldelgass> jrfonseca: I'm hoping to use BM_HOSTDATA instead of BM_ADDR as the GUI-master target register. May 27 18:41:05 <jrfonseca> ldelgass: Sure. Go ahead. When I get back I'll help you. May 27 18:41:32 <jrfonseca> ldelgass: I still have to study what's the use for BM_HOSTDATA.. May 27 18:41:56 <ldelgass> jrfonseca: I was also looking at what's required to do cliprects for vertex buffer emits, it's going to be a little messy since we only have one hardware scissor. May 27 18:42:47 <ldelgass> jrfonseca: Also we need to reuse the vertex buffers, which isn't possible with the current code which has a 1 to 1 mapping of buffers and queue slots. May 27 18:43:18 <jrfonseca> ldelgass: Yes. We need to issue the same buffer with diffrent scissors. May 27 18:43:49 <ldelgass> jrfonseca: I think we'll need to calculate the intersection of a cliprect with the GL scissor if there is one. May 27 18:43:50 <-- McCusker (~[EMAIL PROTECTED]) has left #dri-devel May 27 18:44:44 <jrfonseca> ldelgass: But aren't the cliprects already the only parts we need to draw? May 27 18:45:22 <jrfonseca> ldelgass: Or are they taken directly from the windows system..? May 27 18:45:44 <ldelgass> The scissor could be more rescritive. The cliprects are for exposed areas in the window system. May 27 18:45:51 <ldelgass> restrictive May 27 18:46:15 <ldelgass> the scissor is part of the GL state, specified by the app. May 27 18:46:23 <jrfonseca> ok. I see May 27 18:47:31 <ldelgass> jrfonseca: for cards like r128, the scissor registers hold the GL scissor and the auxiliary scissors are used for hardware cliprects. r128 has 3 aux. scissors/ May 27 18:48:45 <ldelgass> jrfonseca: I was getting confused becuase of the code borrowed from r128. For that reason I moved the scissor registers under UPLOAD_MISC instead of UPLOAD_CLIPRECTS. May 27 18:48:47 <jrfonseca> ldelgass: But how do they interact? It's the intersection or the union of all scissors? May 27 18:50:23 <ldelgass> jrfonseca: I'm assuming it's the union of the aux. scissors intersected with the main scissor, but I don't have r128 docs. May 27 18:50:44 <jrfonseca> ldelgass: Yes. That's seems the most logical. May 27 18:51:31 <jrfonseca> ldelgass: Well, I'm going to see if I work a little more until I go to bed. The soon I get this thing done, the sooner I can resume the work on mach64... Keep up the good work! May 27 18:51:35 <ldelgass> jrfonseca: In some cases, you might be able to eliminate a cliprect if it falls completely outside the scissor. May 27 18:52:07 <jrfonseca> ldelgass: that's surely worthy to check then May 27 18:52:38 <ldelgass> jrfonseca: I'll keep you posted on how it's going. May 27 18:52:50 <jrfonseca> ldelgass: Ok. May 27 18:53:04 <jrfonseca> Good night(?) to you all! May 27 18:53:12 <ldelgass> jrfonseca: cya later! May 27 18:53:17 <-- jrfonseca (~[EMAIL PROTECTED]) has left #dri-devel ("Client Exiting") May 27 18:54:12 <-- AndyF has quit (Read error: 110 (Connection timed out)) May 27 18:59:56 <ldelgass> I'm off to get dinner now, cya later... **** ENDING LOGGING AT Mon May 27 19:00:06 2002
