From: Chris W. <cw...@so...> - 2001-12-03 21:20:01
|
> Well I don't use the extra, but I could :) I was looking for a cheap example > of when you wouldn't want mmap to happen. Some hardware have tiled memory > framebuffers that might not work correctly unless you knew about the > tiling. Intel's tiled memory isn't a problem, but I think some might be. > The extra pitch-width area isn't useless. You can put other surfaces there. > You think of the area as being broken up, but really it is just a thinner > area with the same pitch as the framebuffer. i.e. if your framebuffer is > 800x600 at 16bit, on Intel hardware you have a fb pitch of 2048. That > is an area of 448x600 with a pitch of 2048 that can be used. true true, it would most likly be used as an off screen buffer. I am simply used to having very small pitches (3 bytes or less from24bpp misalignment), but no reason very large ones couldnt exist. mmaping that would be extremely insecure > Maybe this reason works, what if the framebuffer isn't page aligned (both > the > beginning and the end) then you'd get access to memory that you shouldn't. > Drivers could just be careful not to put things that you shouldn't have > access to in the overlap I guess. to me, that'd be a driver technicality, but it does provide an example of where things can go wrong =) > The details aren't important (That's what you say when you can't find a > good reason) but just in case there are reasons why you couldn't do mmap, > we need to account for that fact. accounting for it is simply not putting it in, and coding functionality that isnt dependant upon it. as a feature, rather than a guaranteed item, it's just nice to keep around. good applications would/already should account for mmap failing, and if they dont, they would simply segfault. > Command buffers are just one example. The framebuffer works just as well > as an example although the results are not as catastrophic. Think of > the banked case again. If two apps were trying to both write to the fb > at the same time the hardware would be stuck flipping banks all the time > and never get any work done. Or what if you were doing some interface > where multiple apps alpha blended with the framebuffer? You have to > read->blend->write but without mutual exclusion you can't be sure that > what you read is still there when you go to write. I did several starfield demos back in the day for my vesa1.2 card. bank switching all over the place =). the alpha blending context problem is a real problem though. that would cause _all kinds_ of errors. drat, yet another reason for mmap to go away. and command buffers would almost certainly need to be read/write only (no mmap), but i may be wrong with that. mutexing it would work as well, but it would probably me more complex, and im not sure if mmaping command buffers grants the speed that mmaping fb does. (haven't done any heavy non-fb graphical code). > Whenever you share resources between two processes you need a way to do > mutual exclusion. This is just hard with mmaped areas. Not impossible, > just hard. I'm just giving devils advocate arguments as to why mmap may > be more work than it is worth. Without mmap lots of things become trivial > that would otherwise be very difficult. With mmap you get a speedup in > some operations, but is it worth the pain? to me, the speed up would be a very large asset, esp in regards to raw framebuffer data reads/writes. this day in age, hardware is so rediclously fast that we can realistically say 'hey, lets throw out memory access completely, and let kernel handle it' and not expect our systems to be rendered unusable. but there is a large base of systems that take huge performance hits; not good if linux is to grow off of the server and onto the desktop of real people, not just linux geeks =) though the applications that actually use fb could probably be counted on two hands. the techniques for getting it to work, as you have stated, are completely beyond my understanding (i am but a mere user-land programmer for the most part :), but if they are possible, they might be helpful in the long run. *shrugs* wish i knew more. > I have it working in a test driver now. My issue isn't user apps doing mmap, > it is the kernel behaving as if it has direct access to my hardware when > it shouldn't. I'm not sure how popular my use of zap_page_rang() is going > to be in a driver. We may need to look for another way. where is your source (if any is available online)? i'd be interested in taking a look sometime. you've done far more than i have most likley. > Yes, the DRI suffers from this potential problem (Although except for my > XvMC > work and Mesa no one else uses the DRI) If the user-land driver acts badly > with the lock the whole system comes down. I haven't spent a lot of time on > in but with the read/write interface and mode switching in the kernel a > lot of the reasons for holding the lock outside the kernel go away. i suppose it is the responsibility of the driver writer(s) to make sure the driver is safe. but if it can be kept safe, and keep the system from going down, its ok by me :) chris --- moc.lexiptfos@thgirwc --- |