Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
> So after much tracing with direct netconsole writes (printks > under console_lock not so useful), I think I found the race. Direct netconsole write would be a useful patch to have mainline I think 8) > Hopefully this fixes the problem for anyone seeing vesafb->kms > driver handoff. Not really the proper fix but its clear and is probably the best thing to go in initially with a cc: stable. Can you at least stick a large + /* FIXME: we should sort out the unbind locking instead */ on the patch however. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> They want the benefits of lots of testers, without wanting to be > courteous to those testers. Except for the small rather important detail that the Nouveau developers didn't ask for it to be merged in the first place. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The > guy who is, as far as I know, effectively in charge of that whole > integration. Yeah, I realize that there are other people (Kyle?) involved, > and maybe Dave isn't as central as I think he is, but I learnt from last > time that the nouveau guys don't seem to care. Ok "screamed about" is perhaps better wording. Why should the Nouveau guys care ? You've forced their hand, you've demanded stuff they said they didn't want to do and then you've bitched about things they said they would do. Actually I think they've been quite restrained. I'd probably have proposed a licence change to make it only work on FreeBSD and Solaris given that treatment ;) > Even if you need to change the interface, I've actually looked at the > patch in question (have you, Alan?), Yes but I read it somewhat differently. Someone who never made a commitment to stability decided to do the logical thing. They deleted all the old broken interfaces, they cleaned up their ioctls numbering and they tided up afterwards. I read it as the action of someone who simply doesnt acknowledge that you have a right to control their development and is continuing to work in the way they intended. You can only see it as malicious if you assume they ever had some reason to keep compatibility or had promised it somewhere. Quite the reverse happened, and they never asked to be upstream in the first place. "But the fact is, at least from my standpoint, I'd really hope that anything I had written would be used in ways I asked people to" - Linus Torvalds, 2004 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact > that the thing was done in such a way that it's basically impossible to > support the old/new ABI at all! What did you expect them to do. They said when you first forced a merge that they would do this. They have no contract that I am aware of to deliver you compatibility, in fact quite the reverse they said they wouldn't be. Then you attribute to malice what was done as a cleanup by people who've pointedly never to commited to a constant API yet "That commit seems to _on_purpose_ try to avoid at all cost being compatible." Great way to make friends. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 05 Mar 2010 08:06:26 -0800 (PST) David Miller wrote: > From: Daniel Stone > Date: Fri, 5 Mar 2010 18:04:34 +0200 > > > So you're saying that there's no way to develop any reasonable body of > > code for the Linux kernel without committing to keeping your ABI > > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > > that worked really well for Xlib. > > read() still works the same way it did 30 years ago last time I > checked. Thats disingenous as read() is a method not an interface. It's also wrong because read() and write() behaviour has changed in various ways and old code broke because of it in subtle ways. Keeping the same method behaviour would have required things like new versions of read() for 64bit files, nonblocking, mandlocks, NFS, networking, etc all of which changed the core read() behaviour. I've yet to see anyone meaningfully argue it was the wrong thing to do. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> So the watershed moment was _never_ the "Linus merged it". The watershed > moment was always "Fedora started shipping it". That's when the problems > with a standard upstream kernel started. > > Why is that so hard for people to understand? So why are you screaming at the DRM and Nouveau people about the breakage ? That's the bit I really don't understand. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010 16:56:10 +0100 Luca Barbieri wrote: > It seems to me that Linus' technical argument is indeed being mostly ignored. > > While breaking the ABI is unfortunate, the real problem that Linus > complained about is that you can't install several userspace versions > side-by-side. I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. All the X builds are modular, all the modular builds support --prefix= with their autogen script. ld.so supports LD_LIBRARY_PATH and the shells support PATH variables. You can replace all or almost any part of X quite easily. There is also a mechanism for versioning within DRM for a lot of stuff, and drivers use flags to make it work nicely except for devel code (which is what Nouveau is) The fundamental problem you can't solve by versioning though is the exact one here. A new kernel that requires version X of a driver won't help if the newest version you have is X - 1. Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
On Fri, 05 Mar 2010 07:49:32 -0800 (PST) David Miller wrote: > From: Daniel Stone > Date: Fri, 5 Mar 2010 17:41:43 +0200 > > > I understand that you guys are upset about this, so maybe you'd like to > > donate, say, 10% of your developer base to help out? That'd be pretty > > ace. > > You have to support less than %10 of the amount of hardware we have to > support. If we believe the changelogs including X.org userspace then they also have a good deal less than 10% of the contributors. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> You can't unleash something like this on a userbase of this magnitude > and then throw your hands up in the air and say "I'm not willing to > support this in a reasonable way." Not to belabour the obvious - they didn't. Linus ordered them to merge it. > We're better than that. If you consider the problem is with the Fedora kernel team decision to merge it into Fedora in the first place, perhaps you should have an internal Red Hat discussion about it with the people who made that decision - who I suspect see it differently. Either way the Nouveau developers don't control Fedora packaging policy, in fact the GPL licence specially ensures the control is not theirs. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> Personally I wouldn't have ever committed to that "user visible APIs > can break cause it's in -stable." Because that's complete garbage Staging has to have the no API rules. Read some of the stuff in there to understand why or apply about 30 seconds of thought to what it would mean to you. There are staging drivers using old wireless layers. If you say that no API can be broken from staging then you will have to put the old wireless compatibility into your network code forever. Does that fill you with joy, light and happiness ? Whether nouveau should ever have gone into staging is a different question. I don't personally think its all as clear cut as it might seem. Quite a few distributions ship whacky wireless drivers with old API's as the choice is that or nothing. They manage the user expectation and they deal with the drivers moving from one wireless stack to the other and mostly successfully hide it in userspace. The differences here appear to be - Having no video is more annoying than having no wireless - Userspace failed to hide it (so maybe its not a kernel ABI problem but a failure to anticipate the need for versioned libdrm and the importance in some eyes of supporting the kernel.org kernel - which like it or not is a corner case for distro *users*). - The box it broke happened to belong to Linus but that doesn't really require tantrums or fingerpointing to fix, particularly when its only the combination of a set of decisions and misunderstandings by Linus, Fedora and the Nouveau developers together that combined to create the mess. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> If it effects such a large number of people, which this noveau thing > does, it's entirely relevant to everyone. And the way it's breaking > and making kernel development difficult for so many people matters to > us. > > It's about the tester base, and this breakage shrinks the tester base > considerably. > > Or do you want the kernel tested by less people? I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful working machines. So - do you want Linux used by a lot less people, and to have no Nvidia driver ? See - its all about viewpoints. Do you think screaming at people who did no wrong increases the kernel developer and testing base ? No I thought not. To be honest the big thing I object to here is certain people who should know better behaving like small children. Not just in the sense of throwing their toys around because mummy didn't buy them the right sweetie but in not thinking about how other people see the problem and their actions. - Fedora merged the stuff to make it work and to improve life for lots of users. Good intent, rational logical behaviour - Linus asked for it to be merged and was warned about the ABI. He did that for good, sound reasons. - The developers accepted the merge to staging so they could fix the ABI later, they made that clear - again all good sound intentions - The ABI change and clean up was done - again good sound intentions, rational behaviour - Linus then threw a tantrum. He's right there are issues about how user migration should be handled but he didn't need to go screaming at the DRM people (not their fault), Fedora (who had good sensible goals in what they did) or the Nouveau people (who told him what was going on well in advance and did exactly what was asked of them before) Firstly he's being hypocritical (he keeps saying he doesn't want to control distributions, he even refused to allow ext2 to be merged *until* Red Hat shipped it), he was told clearly, and staging is for unfixed ABIs. Secondly he's shouting at people who all did a right thing, which only produces bad feelings. All that was needed was a "Hey guys, I know its in staging but this is going to be a problem, can we either fix back compatibility or have some kind of migration policy and the tools so I can test it - otherwise I can't merge this" No blaming, no tantrums, no judgemental comments from a single viewpoint. A collection of good intentions produced a problem. It happens all the time, screaming and blaming may be how politicians sometimes behave but we can surely do better ? Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> Why does the X community not understand simple library versioning? Why does Linus Torvalds not understand the Kconfig of his own staging directory ? Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 04 Mar 2010 14:32:02 -0500 Jeff Garzik wrote: > On 03/04/2010 02:04 PM, Matthew Garrett wrote: > > "Please note that these drivers are under heavy development, may or may > > not work, and may contain userspace interfaces that most likely will be > > changed in the near future." > > Shipping it as the default Fedora driver for NVIDIA hardware makes that > text largely irrelevant. Why ? Fedora isn't special, Fedora is just a distribution that uses the Linux kernel. If Fedora turns on staging drivers then Fedora has to accept that stuff breaks and manage that expectation with its users. Staging is not and has not been API stable. If staging is going to be API stable then it it useless and may as well be deleted. In this case Linus is just a random Fedora user having a distro problem. I don't even see what it has to do with linux-kernel. The libdrm problem and difficulty using Fedora libdrm with current upstream kernel is a Fedora problem not a kernel problem. The kernel staging tree is unstable for API. Whether thats the Nouveau guys breaking Fedora, submissions to network drivers breaking/removing bogus APIs in stuff being cleaned up - whatever then thats how the cookie crumbles. DRM has just made it all horribly more visible because the libdrm/kernel stuff has such a complex and closely tied interface. Serious discussion point perhaps should be: is the libdrm so close to the kernel it ought to be in the same git tree ? Alternatively does it need to be easier to have multiple Nouveau libdrms autoselected according to the kernel side versioning. ELF library versioning is not rocket science and both the old and new libraries exist and can be installed so all the bits are present except for the wrapper to load the right sublibrary yes ? Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> So man up, guys. Face the problem, rather than say "well, it's staging", > or "well, we can revert it". Neither of those really solve anything in the > short run _or_ the long run. Linus stop and think for a minute instead. Maybe a timeline would help Nouveau development starts People ship highly experimental stuff for testers Code gets to the "works but really needs a clean up point" Linus demands it is merged Linus gets it merged as staging Developers start doing the cleanup Linus throws a tantrum because they did the cleanup after merge *YOU* forced the early merge (rightly or wrongly) *YOU* effectively created the API break problem So blaming other people is quite out of order. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
> The conclusion is crystal clear, breaking an ABI via a "flag day" > cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI - its called not RTFM. Alan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
> Obviously I'd like to clean it up, though. > > So, what device should handle this in your opinion? My guess would be the relevant device driver for the hardware layer So fbcon would probably not switch because it can put video modes back, KMS obvious likewise. The text console might do something as part of its suspend/resume path IFF the vt in question is in graphics mode. Alan -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
> > But in that case we should be able to disable the VT switch disable > > path; we just have to check each driver as it's loaded. > > OK, what the right sequence of checks would be in that case and where to place > them? Why are we even driving a vt switch direct from the suspend/resume logic ? The problem starts there. If it was being handled off the device suspend/resume method then there wouldn't be a mess to start with ? Start at the beginning - Why do we switch to arbitarily chosen 'last vt' - Why isn't vt related suspend/resume handled by the device Alan -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
> This probably belongs in the core DRM KMS code instead of the driver. > I can imagine that there may be some X driver code that still needs to > be executed on suspend/resume for some drivers, so this may introduce > bugs, but it's definitely the right way to go. You can have a mix of KMS and non KMS consoles active on different cards. So I don't think that is the case. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
> I've been testing this patch for over a week and haven't seen a single problem > related to it during this time. > > Are there any objections to it? Usual question 8) - explain the locking. What happens if we suspend as kms is initialising/being removed. Also what happens if you have KMS and non KMS consoles both active through the frame buffer off different cards ? -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
On Fri, 15 Jan 2010 12:40:30 + (GMT) James Simmons wrote: > > > > Yeap. I can have patch ready for you this weekend. I lack the hardware to > > > test it tho. Never been able to find a intel pci card that is not built > > > into the motherboard. > > > > They don't exist, other than the old i740s. > > I noticed the same is true for SiS cards. SiS 6326 is a plug in card. Also prehistoric. I did a basic DRM for one before deciding it would be faster to use the CPU (or indeed crayons ;)) -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Fri, 11 Dec 2009 07:45:41 -0500 ty...@mit.edu wrote: > On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote: > > > > Well the main thing was I wasn't mean to discuss possible legal issues > > and still don't have permission, you know as well as I do once lawyers are > > involved you have to keep out of things until they deal with them. > > The thing which really surprises me is that if there are legally > dubious issues, why on *earth* did Red Hat allow Fedora to ship said > code? The thing which really surprises me is that if there are legal questions involved why on *earth* do people keep asking them on public mailing lists when they know the lawyers views/opinions/decisions will not be publishable there ? Ted, you of all people know that if you want to get an answer that isn't the way to get it. Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> I realize that you have some emotional attachments to Red Hat, but ask > yourself (and answer honestly): what would you think if some random other > distro was packaging tens of thousands of lines of kernel code and not > apparently working at trying to get them upstream? Like Ubuntu does for a load of stuff and did for years ? I'd like to see stuff get upstream yes. The point you seem to be missing is you are ranting at the wrong people. I want to see it upstream too, but if you must shout at people do it productively at the right target. I would be cross if they were controlling and hiding it, but its sitting in a public repository, its maintained by a collection of people one of whom happens to work for Red Hat and anyone can grab it. It's vastly easier to get hold of than the userspace for some of the stuff in kernel. However the fundamental point stands. The only people who can sign it off are the people who wrote it. Those are the rules. Red Hat didn't write the code, Red Hat cannot sign it off however much you rant at them. You also previously said you don't want to merge stuff when the authors don't want it merged. If you like I can also dig out some Torvalds quotes about not wanting to dictate to distros. If you want to progress this then - Starting talking to the project *authors* - Help them decide what to do about the firmware stuff - If need be get the Linux Foundation, Red Hat and other relevant lawyers and people on a phone call with you so that legal issues can get discussed and you can shout at them as necessary too. I am not privy to what the lawyers think on this one. But I'd bet that the only way you'll get a full answer is in conjunction with lawyers speaking to lawyers, and the only way you'll get a sign off is when the lawyers say "yes". Anything else would be rather irresponsible. > And it's possible that other distros are doing the same thing. I happen to > know that Fedora does it (and has been doing it for at least a year), > because I happen to have an Intel development machine that runs Fedora and F11 certainly shipped some bits of it for 2D support. I am not sure if F10 shipped a purely userspace set up. Neither had it enabled as the default driver - they used "nv" or "vesa" depending upon the card. > was shipped by Intel with an nVidia card (and has a power supply that > craps out if you don't use several hundred watts of power, so I can't > change it to something more power-efficient - seriously). Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> But not only is Fedora not following the rules, You changed the rules. You require a Signed-off-by:. Fedora can no more add a signed off by than you can. It's not their code nor Red Hat's code any more than they "own" the kernel because they pay someone to work on it. > See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and > shipped it, I wouldn't care. And zillions of Nvidia users would have been worse off. It's really simple: if you want to merge it *you* pull it and sign it off. If you aren't prepared to do that then ask why Fedora should, its not their code either. Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> The big question is what we call ctxprogs: binary blobs that are > clearly executable, running somewhere in the GPU. No-one seems > to know, if those are copyrightable, or if they can be redistributed. > In their current form, they have been recorded from the nvidia > proprietary driver using mmiotrace, and copied verbatim for each > card type. Don't suppose they binary match anything in the Nvidia driver so you can simply tell people where to extract it ? -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> The fact is, if there are license questions, then Fedora had better not be > distributing the code either. And they clearly are. Their choice, but it's not their project - they are just chosing to import it. > I've heard the "but it's hard to merge" excuse too - which I also know is > bullshit, because I can look at the git tree Fedora apparently uses, and > it merges without any conflicts what-so-ever. So merge it - it's your call as the maintainer of the master tree - or put it in staging and dike out the microcode - which is firmware tree stuff *anyway* Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> Last time they were asked that, they wanted to be free of changing their > kernel/userspace interface before upstreaming. So put it in staging with a note to that effect. That'll also get it more exposure and review. Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> I think "tightly integrated" could do with some clarification here. > qcserial was accepted despite not being functional without a closed > userspace component - an open one's since been rewritten to allow it to It got as far as staging with a good deal of complaint. I am not sure it would have gotten further unfixed (with my serial/tty maintainers hat on ;)). That however was about firmware - so a lot less tightly coupled. > work. Do we define "tightly integrated" as "likely to cross the GPL > line" (potentially the case with Poulsbo, not the case with qcserial), > or is it a pragmatic issue? What about specialised hardware drivers that > only have closed applications? Ultimately - ask a lawyer, ultimately this is a question about works and copyright boundaries. If the hardware has only some specific proprietary app then it sounds to me like it's not a general kernel interface so probably isn't a good interface anyway, let alone what the code may do. Alan -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> Greg still claims that qcserial could be used by rebooting from Windows, > right? In that it would still be extremly borderline to me, but it's qcserial has a firmware loader app nowdays (someone wrote one in April) http://www.codon.org.uk/~mjg59/gobi_loader/ indeed Matthew wrote it 8) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> If the common agreement of the linux community is to *NOT* allow these > drivers in, so be it, then be honest and go ahead and tell the driver > writers. Don't make them respin their development trying to fix minor > flaws when their driver won't get in anyway! The existing policy based on what has been rejected is: - If you have something which only works with some non-free tightly integrated software then we don't accept it Examples - GMX500, Intel wireless regulatory daemon. So until there is an open source user and test case for the kernel code it has no place in the kernel (and indeed if the two are closely interconnected and dependent then there are good 'talk to your lawyer' reasons as well) Once there is a useful combination of kernel/user space free software for the card then it makes sense to look at a merge. Until then you don't even know what the final interface will look like and what is actually needed kernel side. The VIA stuff might be a useful basis for that work but that is a when/if anyone ever writes drivers for it. My guess is that if someone cares enough about the hardware they need to get EXA working along with 2D render, then submit the bits the need to do hardware rendering. After that tackle what is needed for 3D - as is happening with the Nvidia drivers and then submit a DRM module for their work. Alan -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> * fully functional GPL user-space driver. > > How can you argue that something as tailor made as a DRM interface can > be used without it being a derived work? Our prior policy has been to reject such stuff (both the Intel wireless driver regulatory daemon and the GMX driver) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
> > By the same logic, would you support including the proprietary NVIDIA > > driver while we wait for Nouveau to catch up? > > The license of the NVIDIA driver does not allow that to even be a > possibility. I'm not convinced this is any different. If you accept the 3D changes you step into a dangerous world of estoppel and since it has many rightsholders also the wonderful world of contributory infringement. It really really needs lawyers to look into it. Now the other way to do it that might be more productive and simpler would be to rip all the 3D crap out of that driver and just include the minimum needed 2D bits for the open source X driver. Makes the code smaller and cleaner, avoids an legal questions and lets people get on with real work. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
> The non-existence of an open-source 3D implementation doesn't really > alter that situation. I think it does to an extent > > However, if there's a policy issue about adding Linux kernel support for > closed-source user-space drivers, I think it helps to be explicit about > that. Actually its a lawyer question not just policy. If the two parts being put together are tightly dependant on each other and in fact form a single work which it seems could reasonably be the case in this situation then if one half is GPL the other must also be so. There is also policy on this, I refer you back to the Intel wireless and binary management daemon discussions. I likewise refer you to some of the input device discussions related to USB HID and devices where vendors wanted us to exclude their device in favour of proprietary libusb drivers. Alan -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: in-kernel DRM tree move around....
On Thu, 29 May 2008 11:05:08 +0200 "Alexander van Heukelum" <[EMAIL PROTECTED]> wrote: > On Thu, 29 May 2008 10:46:22 +1000, "Dave Airlie" <[EMAIL PROTECTED]> > said: > > Hi, > > > > So I've been growing more annoyed with the current layout of the drm > > tree in the kernel, > > > > a) it lives under char. > > b) everything in one directory. > > c) header files in one directory. > > d) no header files exposed to userspace. > > > > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=7df9a948d0f849466e3de259cccb49bc54cbad68 > > > > is a proposal to create drivers/gpu/drm, (I may move AGP in there as > > well later). It also creates per-driver subdirs. > > Looks like a lot more suitable place! I just wonder if drivers/video/drm > would be even more logical? I think gpu is better - we are seeing various GPU as CPU accelerator toolkits appearing and assuming the AMD one ends up open source we will end up with gpu/something that isn't video. Remember GPU = Grahi^WGeneric Processing Unit ;) Alan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Push BKL down into drivers
This is a fairly simple change but affects all the drivers. The actual
lock is pushed down rather than eliminated. Hopefully it will then get
pushed down further. More importantly it helps us get rid of the old BKL
locked ioctl
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff --git a/drivers/char/drm/drmP.h b/drivers/char/drm/drmP.h
index 213b3ca..c545ccb 100644
--- a/drivers/char/drm/drmP.h
+++ b/drivers/char/drm/drmP.h
@@ -888,7 +888,7 @@ static inline int drm_mtrr_del(int handle, unsigned long
offset,
/* Driver support (drm_drv.h) */
extern int drm_init(struct drm_driver *driver);
extern void drm_exit(struct drm_driver *driver);
-extern int drm_ioctl(struct inode *inode, struct file *filp,
+extern long drm_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
extern long drm_compat_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
diff --git a/drivers/char/drm/drm_drv.c b/drivers/char/drm/drm_drv.c
index fc54140..a494869 100644
--- a/drivers/char/drm/drm_drv.c
+++ b/drivers/char/drm/drm_drv.c
@@ -435,7 +435,6 @@ static int drm_version(struct drm_device *dev, void *data,
/**
* Called whenever a process performs an ioctl on /dev/drm.
*
- * \param inode device inode.
* \param file_priv DRM file private.
* \param cmd command.
* \param arg user argument.
@@ -444,8 +443,7 @@ static int drm_version(struct drm_device *dev, void *data,
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev = file_priv->minor->dev;
@@ -457,6 +455,8 @@ int drm_ioctl(struct inode *inode, struct file *filp,
atomic_inc(&dev->ioctl_count);
atomic_inc(&dev->counts[_DRM_STAT_IOCTLS]);
+
+ lock_kernel();
++file_priv->ioctl_count;
DRM_DEBUG("pid=%d, cmd=0x%02x, nr=0x%02x, dev 0x%lx, auth=%d\n",
@@ -519,6 +519,7 @@ int drm_ioctl(struct inode *inode, struct file *filp,
atomic_dec(&dev->ioctl_count);
if (retcode)
DRM_DEBUG("ret = %x\n", retcode);
+ unlock_kernel();
return retcode;
}
diff --git a/drivers/char/drm/i810_dma.c b/drivers/char/drm/i810_dma.c
index e5de8ea..b82e8ed 100644
--- a/drivers/char/drm/i810_dma.c
+++ b/drivers/char/drm/i810_dma.c
@@ -115,7 +115,7 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
};
diff --git a/drivers/char/drm/i810_drv.c b/drivers/char/drm/i810_drv.c
index fabb9a8..c1e0275 100644
--- a/drivers/char/drm/i810_drv.c
+++ b/drivers/char/drm/i810_drv.c
@@ -59,7 +59,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
diff --git a/drivers/char/drm/i830_dma.c b/drivers/char/drm/i830_dma.c
index a86ab30..8045e7a 100644
--- a/drivers/char/drm/i830_dma.c
+++ b/drivers/char/drm/i830_dma.c
@@ -117,7 +117,7 @@ static int i830_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
static const struct file_operations i830_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i830_mmap_buffers,
.fasync = drm_fasync,
};
diff --git a/drivers/char/drm/i830_drv.c b/drivers/char/drm/i830_drv.c
index 389597e..44f990b 100644
--- a/drivers/char/drm/i830_drv.c
+++ b/drivers/char/drm/i830_drv.c
@@ -70,7 +70,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index bb8f1b2..a05f44b 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -556,7 +556,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+
Re: initial multi-master support for the drm..
> Interrupt handler - userspace plays with the irq lines, I think we could > have issues getting interrupts when we have no master. Undoubtedly - PCI interrupts are asynchronous to the other busses and can turn up suprisingly late. It ought to be sufficient to clear the IRQ cause kernel side and provide a way to pass it (or fake it ;)) to the new master the moment it attaches. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
> At a minimum, there must be a program to determine which outputs have > monitors > attached, and what modes are available on those monitors. It's possible this > could be hardcoded in simple or embedded cases, but for a dynamic system it > should probably be done in userspace, since EDID overrides will be fairly > common, and various platform specific quirks will probably be necessary. It needs to be hotpluggable to work properly on modern systems. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: uncached page allocator
> allocate pixmap gets cached memory > copy data into the pixmap > pre-use from hardware we flush the cache lines and tlb > use the pixmap in hardware > pre-free we need to set the page back to cached so we flush the tlb > free the memory. > Now the big issue here on SMP is that the cache and/or tlb flushes > require IPIs and they are very noticeable on the profiles, Blame intel ;) > Any other ideas and suggestions? Without knowing exactly what you are doing: - Copies to uncached memory are very expensive on an x86 processor (so it might be faster not to write and flush) - Its not clear from your description how intelligent your transfer system is. I'd expect for example that the process was something like Parse pending commands until either 1. Queue empties 2. A time target passes For each command we need to shove a pixmap over add it to the buffer to transfer Do a single CLFLUSH and maybe IPI Fire up the command queue Keep the buffers hanging around until there is memory pressure if we may reuse that pixmap Can you clarify that ? If the hugepage anti-frag stuff ever gets merged this would also help as you could possibly grab a huge page from the allocator for this purpose and have to flip only one TLB entry. Alan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 4 of 5 ] /drivers/char/rio ioremap balancing/ returncode check
On Mon, 13 Aug 2007 00:05:30 -0400 "Scott Thompson" <[EMAIL PROTECTED]> wrote: > patchset against 2.6.23-rc2 and this set is an audit of > /drivers/char/a* > through drivers/char . > > this corrects missing ioremap return checks and balancing on > iounmap calls.. Your mail client has wrapped the patches. Please resend without wrapping - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AGP/DRI: Question about aper_size_info structs in agp.h
Ar Mer, 2006-08-23 am 15:24 +0200, ysgrifennodd Gerhard Pircher: > BTW: Can anybody explain the format of the graphics address remapping table > or point me to some docs where it is described? Its usually described and defined in the chip documentation. Generally speaking it is a simple linear array of translations identifying which page address is mapped to which gart address. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: adding dri support
On Maw, 2006-01-31 at 10:24 +0100, Philipp Klaus Krause wrote: > The SiS 530 is fully documented, but it's a bit outdated and AFAIK > there's no 3D driver for it yet. > AFAIK The Vodoo cards are fully documented and the driver is so bad it > could need a rewrite. The Voodoo 3 and higher need a lot of support above the DRI layer fixing to get some features like SLI working at all. Right now the 2D engines in X don't support SLI. Voodoo2 is also documented but DRI for it while practical might be a little esoteric. I've always wanted to add DRI to it but never had the justification/time ;) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: map user space memory as gart memory for intel integrated graphics chip
On Iau, 2005-12-08 at 19:52 +0800, Austin Yuan wrote: > buffer. Because the interface of "alloc_by_type" only receives a > simple parameter "type", here I hide the user space address into > "type" and re-get it in alloc_userspace_memory. That should probably be fixed by extending the API to pass both > I use this interface to easily implement XAA readpixmap/imagewrite > driver interfaces, and get a better performance. Here, I didn't attach > the patch for i810 driver. I just want to get some comments about it, > and if you think it makes sense, I'd like to make it more generic. > > Any comments are appreciated, thanks. The one thing I don't understand looking at this is that I understood AGP pages should be marked uncached. However user space pages may exist in many mappings and the CPU also requires all mappings of a page are consistent. Does i8xx need the page uncached or is it enough to wbinvd the pages in question on writing and invalidate them before reading, or does the i8xx in fact take full part in the cache coherency ? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.14-rt4: via DRM errors
On Gwe, 2005-11-25 at 14:23 -0500, Lee Revell wrote: > On Fri, 2005-11-25 at 20:13 +0100, Arjan van de Ven wrote: > > of course sometimes having less but more coarse locks is actually > > faster. Taking/dropping a lock is not free. far from it. > > True but couldn't it be a problem for devices like unichrome where you > have 3D and MPEG acceleration and they have to play nice? It just seems > like there may have been an implicit assumption that devices only > support one type of hardware acceleration. Not really. The DRI locking is what the driver makes of it. Generally GPUs are internally very coarse grained and don't like doing different jobs at the same time anyway. The nearest thing I think to look at it as would be futex locks, and DRI could probably use futex locks with some glue for the X authentication side of things. However futex locks are not in FreeBSD and may never be (IBM patent questions for non-GPL), and DRI predates futexes by a large margin. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.14-rt4: via DRM errors
On Iau, 2005-11-24 at 05:49 -0500, Lee Revell wrote: > BTW can you point me to a good explanation of DRM locking? There's so > much indirection in the DRM code I can't even tell whether there's one > DRM lock or several, what kind of lock it is or what it's protecting > (beyond "access to the hardware"). Is it just an advisory lock used by > DRM clients to keep from stepping on each other? It doesn't seem > related to spinlocks or mutexes or any of the other types of lock in the > kernel. It co-ordinates access between the X server and various 3D clients so that they don't step on each others drawing. A shared memory area is used to co-ordinate other things like clip lists and what context may have been stomped by another user if when you retake the lock you were not last holder. Precisely what it protects is board dependant --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mach64 still not in kernel tree
On Mer, 2005-11-23 at 11:46 -0500, Adam Jackson wrote: > On Wednesday 23 November 2005 07:48, Michael Frank wrote: > > Testing 2.6.15-rc2 in-kernel DRM, why still no mach64 > > support which works fine for me from snapshots/cvs? > > Because it's still insecure. Michael - If you've got a Mach64 and you want it mainstream you need to add code which validates the command stream passed to the chip is valid. There is code like this in the VIA driver and the Mach64 needs something similar to verify you aren't doing things like DMAing patches into the kernel with the graphics card but only using commands that are "safe". --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux OpenGL ABI discussion
On Iau, 2005-09-29 at 22:02 +0200, Christoph Hellwig wrote: > And replacing system libraries is not something we can allow anyone. > It's totally reasonable to have different 3cards in the same systems > and they're supposed to work. Agreed - but the LSB job is still that of defining an ABI. Obviously users who replace system libraries with ones they got from another source get burned whether its a perl "upgrade" required by a vendor or libc. Alan --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux OpenGL ABI discussion
On Iau, 2005-09-29 at 09:49 +0200, Christoph Hellwig wrote: > On Wed, Sep 28, 2005 at 04:07:56PM -0700, Andy Ritger wrote: > > Some of the topics raised include: > > > > - minimum OpenGL version required by libGL > > - SONAME change to libGL > > - libGL installation path > > I think the single most important point is to explicitly disallow > vendor-supplied libGL binaries in the LSB. Every other LSB componenet > relies on a single backing implementation for a reason, and in practic That is not actually true. It defines a set of API and ABI behaviours which are generally based on a single existing common implementation. > the Nvidia libGL just causes endless pain where people acceidentally > link against it. The DRI libGL should be declare the one and official > one, and people who need extended features over it that aren't in the > driver-specific backend will need to contribute them back. If the LSB standard deals with libGL API/ABI interfaces then any application using other interfaces/feature set items would not be LSB compliant. Educating users to link with the base libGL is an education problem not directly inside the LSB remit beyond the LSB test tools. In addition the way GL extensions work mean its fairly sane for an application to ask for extensions and continue using different approaches if they are not available. In fact this is done anyway for hardware reasons. There is a lack of "is XYZ accelerated" as an API but that is an upstream flaw. Alan --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri client framebuffer access..
On Llu, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: > Do we need to restrict the size of the maps we allow the DRI clients to > acess in the FB area? Yes - SiS has a 64K command queue in the frame buffer for example --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: via PCI DMA blitblt added.
On Sul, 2005-09-25 at 15:06 +0200, Thomas Hellstrom wrote: > *VIA docs are rumored to require the (src_addr%4 == dest_addr%4) for all > lines, and this is what is implemented as a sanity check. However, > apparently there is a bug in the chip that also requires (system_addr&15 > == 0) for all lines. VIA has been contacted about this, but have failed > to provide any answers. If these alignments cannot be met, a user-space > bounce buffer needs to be used, and this will be implemented for Xv. Really EXA needs to allow the driver to specify this and allocate padded and aligned buffer blocks when neccessary. That would avoid the rather undesirable bounce buffer second copy. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
On Gwe, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: > drivers) also setup an mtrr which frequently stops subsequent processes > from adding a new one that overlaps an existing write-combining range. It expects the other users to have the brains to add non-overlapping ones 8) > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > like to remove it from them too :-) or at least default those to off) Sounds sane. Nvidia posted some patches a while ago that seem to be getting kicked around a bit again to add support for PAT (per page attributes) on PII Xeon and higher which will help no end --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Wondering about PC graphics that implements SGI style virtual graphics
On Maw, 2005-09-13 at 12:24 +1000, Tim Long wrote: > I have tracked down the orignal paper on the subject online at: > http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/The% > 20Graphics%20Pipeline/Virtual%20Graphics.pdf SGI were doing it before that paper, years before. I think Mark Kilgard's original direct render paper discusses it a little > > I am wondering if any PC level hardware implements the same features? > For the ones that don't what sort of performance impact does it take > switch GL threads if the pipeline has to be flushed on a context > switch. Ideally you flush the pipeline when someone else has to be given a context and this is the oldest. The same is done at low levels for MMU tags and the like. That way context flushing rates are much lower --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Mer, 2005-08-24 at 11:18 -0600, Brian Paul wrote: > > 2. 1MB of the card memory is allocated for the front buffer and pinned. > > 3. Process A allocates (and commits) a 7MB region for a big texture. > > 4. Process B allocates (and commits) a 2MB region for a texture. To do > > this, it kick out part of process A's allocation. > > 5. Process A re-commits its 7MB texture. > > > > At #5 we'd much rather just upload the damaged 1MB than have to upload > > the whole 7MB. This is just a simple example, but the same scenario > > happens with larger on-card memory + AGP memory and larger textures. > > This sounds fairly complicated (both for the implementor and the user). > > Is there anyway we could live without that feature and just manage > things at the granularity of whole regions for version 1.0? If you make the API return a bitmap at some sane granularity (say 256K ?) then you can implement 1.0 the naiive way and have the API just continue to work once the underlying code is smarter. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Maw, 2005-08-23 at 14:48 -0700, Keith Packard wrote: > I'm starting to look at multi-user environments where each user has an X > server which isn't in control of the whole screen, but rather just > paints X windows into off-screen memory where an external trusted > application can take those applications and merge their contents to the > final screen. That should be less of a problem as you are then dealing with large chunks of memory for the mmap() calls and can just map the chunks you need into each process. DRM might have a role in arbitrating those if the off screen memory in question is on the video card. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
> The framebuffer (including color, Z, stencil, etc) > Pbuffers > Renderbuffer/Framebuffer objects > Pixel/Vertex buffer objects > Texture images > OpenGL miscellaneous (e.g. vertex/fragment programs) > X server miscellaneous (pixmap cache, etc) Most of these are fairly static objects. > 1. The location of the object in memory (perhaps the framebuffer has > to be at the start of memory). > 2. Particular byte/word alignments > 3. Can we use VRAM and/or AGP memory for the object? > 4. Can the object can be lost asynchronously (Pbuffers)? and textures. > 3. Blocks should get automatically freed when the process that creates > them terminates (unless they're shared w/ another process, perhaps). We normally refcount objects. You have to do that anyway to deal with horrible cases that crop up where you can't just recover an object on the spot because of DMA and the like. > 6. There should be a mechanism for the allocator to notify a process > when one of its blocks is moved/ejected/changed. Architecturally hard from the kernel side and almost always going to cause bugs. Better that the lock() request discovers the the object is gone than a notification system. > 7. The public interface to the allocator should be OS-independent so > that it can be implemented on Linux, FreeBSD, etc. Perhaps the public > API would be exposed through a library which wraps an OS-specific > interface based on ioctls, etc. The natural way to express it in Linux would be mmap and some kind of device or filesystem perhaps not dissimilar to posix shared memory support. Most of the properties just "happen" when you have such an interface - refcounting, callbacks on exit, address assignment etc. How about BSD - similar ? --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
> The log design presents numerous opportunities for rogue processes to do > bad things. At some level, that's inherent in the nature of direct > rendering. If you don't trust the processes, don't enable direct rendering. Thats a very poor answer to the problem. DRI needs to be moving towards being more secure, and building in assumptions of insecurity just makes it worse when better cards are used. Its critical that the kernel knows what memory on the video space is being used for command queue and protects it. From the description of the SiS turboqueue I suspect you may be able to root a sis video box that way but without full docs I can't tell. Other stuff like textures is merely annoyance value. Knowing who owned a block for cleanup matters and the DRI lock/mem handling on some chips already handles it. Its also cheap because you only have to track some kind of texture handles not pages for cleanup. Alan --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Maw, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote: > > Another part would be to only allow mapping owned parts of the > > framebuffer. > > > > You'd have to get the cliprects from a trusted source then... Memory management hardware isn't that fine grained. Doing cliprect register access via the kernel would work for some chipsets and not be too heavy handed (and no cost in the usual game case). --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Maw, 2005-08-23 at 20:45 +0300, Ville Syrjälä wrote: > Is there any way to make that work without going to the kernel for each > allocation? Personally I'd like to have the protection even if it > degrades performance slightly. X allows applications to read the displayed video memory anyway so what is the big deal here ? You can do memory protection outside of command streams pretty cheaply. If the DRM kernel modules controls which blocks of video ram are mapped into which task then you get memory protection. You will need some kind of reclaim handler to steal memory from other tasks and revoke their pages. That *is* expensive especialy on SMP. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: State of the SiS driver
On Sul, 2005-08-14 at 21:03 +0200, Philipp Klaus Krause wrote: > > not yet. Alan Cox had a semi-working version here: > > http://www.linux.org.uk/~alan/sis6326.tar.gz > > This only contains the DRI part. Does that mean it uses the same > DRM as the 305? There is a small patch to the 2D driver needed and the 3D driver needs the PCI ids adding. As it stands the sis6326 driver bypasses the DRM most of the time at the moment for debugging and just whacks the hardware as root. I can dig out the other bits if you are interested but I would suggest a better idea would be to buy a real video card 8) --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DMA bitblt pageing?
On Gwe, 2005-07-08 at 09:18, Thomas Hellström wrote: > Is this because they are not physically contigous or because they may not > be accessible to the PCI device? I was thinking of using vmalloced memory > instead of kmalloced for the device sg-list, and since it is a linked list > it should be able to deal with non-contigous pages. It may not be physically accessible. The dma allocation functions should be used to reliably allocate DMA spaces. > Preferrably I'd like to have an implementation where one can start a DMA > bitblt operation then return to whatever is being done at the moment, and > a sync function called to make sure the DMA has finished. This will > require, however, a small sg-list / page pointer array ring buffer and > that all free() and unlock operations can be done from the DMA complete > interrupt handler. This is near enough how video4linux works except that it uses a ring buffer rather than keep freeing (as its TV capture) so only does the pci write to stop, read to avoid posting and free at close time. Alan --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DMA bitblt pageing?
On Iau, 2005-07-07 at 23:50, Thomas Hellström wrote: > 1.) get_user_pages() should presumably lock a page into physical memory. > Will this always cause a segfault for an invalid address? You'll get an error for invalid space. You may also get null entries in the array for locking the paged if they relate to a hole in memory. > 2.) Unlocking pages previously locked with get_user_pages(): is > page_cache_release() sufficient or are more calls needed? Could the > unlocking functions be called from an interrupt handler? Is a refcount > maintained for this page locking or is it one-level only? It is refcounted. > 3.) Is memory allocated with vmalloc always locked into physical memory > until freed? Yes but it may not be DMAable. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sul, 2005-07-03 at 05:04, Jon Smirl wrote: > There are three DRI drivers with no DRM. What is up with these? > gamma > s3v > trident trident was never finished s3v and gamma were both against old DRM and are not shipped in curren trees --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Llu, 2005-06-27 at 01:02, Eric Anholt wrote: > > definitely vote for 120. You will need to do some manual touch up > > after Lindent. It will mess up formatting of C99 initializers and some > > constant blocks. > > Please, 80 is standard. Not for most code I've looked at. 80 generates horrible formatting like printf( "hello", x, y+5); all the time. Disagree also about axing the comment - its useful to know why something is being done. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
> I very strongly believe that the right model moving forward is for > user-mode to say to the kernel, "I beg of thee. Initialize thyne self." Much of the initialization of chips is complex and messy and not neccessarily good kernel material. SAREA setup I agree seems an obvious kernel thing to do except that we need to figure who decided what size it should be. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On Sad, 2005-06-18 at 16:54, Jon Smirl wrote: > How about this as a safe first step: > 1) Remove the general root capability check > 2) Change the semantics of the root_only field on these calls to mean > master only. > 3) Push the root capability check into each of these IOCTL individually. > 4) Leave a root capability check on the general switch code to per > device IOCTLs if they are marked master only. This sounds like a way to make mistakes. Far better is to make the check a set of flags where 0/1 happen to keep their meaning ie #define DRM_NEED_ROOT 1 #define DRM_NEED_MASTER 2 now anything you miss/forget to touch won't go off in your hand so to speak. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Sad, 2005-06-18 at 20:22, Jon Smirl wrote: > Then this is a card by card problem. If user space needs to get to the > registers, and we can't split the safe registers from the unsafe > (security issues) ones, then the user space drivers also needs to run > as root. Incorrect. See the via driver. The maps are just a useful performance trick for some cards. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Sad, 2005-06-18 at 23:30, Adam Jackson wrote: > The issue is that drmAddMap, the function that sets up these maps, is > currently run from the server during DDX bringup. These maps can just as > easily be created during DRM init - and as a design issue, probably _should_ > be created there. And if we do that, nothing else in the server-side libdrm > API needs to be run as root (that I can see). In some cases the maps cannot come into existance until the X server has done the neccessary configuration to make the mapping of registers safe. Similarly there are dependancies at points like mode change that require care with what is exposed and active in order to avoid lockups. Currently the X server handles this and whoever handles this needs to be priviledged as they are able to get it wrong. Alan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: need help writing driver for SiS m650
On Llu, 2005-06-13 at 11:28, Matt Sealey wrote: > You have a good point. I still say it would not endear you to SiS. > It is way too easy for them to be spiteful than help. As I understand it SiS no longer own the graphics parts anyway but they were merged with trident and dumped off somewhere. It is possible to get somewhere with .tw vendors, but it does take time, persistence and patience to find the right people. At least we've been successful to a reasonable extent with vendors like VIA and ALi. You might want to contact Richard Stallman as he was talking with several .tw vendors recently and may have contacts he can share or insight into the situation with SiS. Alan --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Mer, 2005-05-25 at 21:42, Michel Dänzer wrote: > Anything that isn't used for pre-R300 chips as well, as those don't seem > to suffer from the same kind of lockups. Assuming alignment is just performance could be erroneous if there are chip bugs like interlocking errors however, or end of ring funnies --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting DRI working on PCI MGA cards
On Mer, 2005-05-11 at 02:16, Ian Romanick wrote: > I was afraid of that. :( The problem is that the MGA can *only* DMA > commands & vertex data from "PCI" memory or AGP. In the case of the > G200 (typically only 8MB), you don't want to use 1/8th of your on-card > memory for commands either. I'll have to dig deeper and see if there's > another way around this. Getting physically linear allocations out of the kernel after boot for anything more than about 64K is very touch and go. If you can use the IOMMU for it then you can get 1Mb of virtual space fairly sanely and map it. If you actually need that much. Given your card will be chugging along far more slowly and the transfer rate is far slower I doubt 1Mb would be needed. You've got a good chance of grabbing 128K linear early on at least for testing purposes. Alan --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting DRI working on PCI MGA cards
On Maw, 2005-05-10 at 22:59, Ian Romanick wrote: > 2. Primary DMA buffer. The DDX carves of 1MB for the primary DMA > buffer. I don't think that's outside the reasonable realm for > drm_pci_alloc. If it is, can this work with a smaller buffer? You'll have trouble grabbing that linearly from main memory, on the other hand I'm assuming most traffic is outgoing so you want the buffer in video card memory if possible and set write combining ? --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_WAIT_ON changed behaviour.
> This in itself is a little bit strange since, if the following occurs: > > * Check condition > * if false, go to sleep > > and DRM_WAKEUP is called by the interrupt handler in between those two, > the sleep should never occur, which now it seems to do anyway. Is the current code still using the deprecated sleep_on type functions ? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: huge allocation in sis drm.
On Gwe, 2005-03-11 at 19:42, Dave Jones wrote: > We got a bug report in our bugzilla from a user that saw > SiS DRM crashing when he restarted X. This object could be vmalloc()'d --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Page flipping using the video overlay
On Iau, 2005-01-06 at 18:36, Felix KÃhling wrote: > Hi all, > > has anyone ever considered using the video overlay for 3D page flipping? > It always bothered me that the page-flipping method used by the radeon > drivers is so complicated WRT 2D/3D interaction and it would even stop > working when (if?) we switch to allocating back buffers per-client. So I > thought, couldn't you use the video overlay to display the front buffer > and do page flipping by switching the video overlay between two front > buffers? Video overlays are expensive. Its doubling the memory bandwidth or worse. It seems to make much more sense to have an Xaa stackable module that can issue Xaa requests to both buffers. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Maw, 2005-01-04 at 09:18, Alan Hourihane wrote: > The DDX and DRM driver are still in the DRI CVS on the trident-0-0-2 branch. 0-0-2 seems to be empty, but 0-0-1 has code ?> --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Llu, 2005-01-03 at 14:46, Sjoerd Langkemper wrote: > Hello, > > I would like 3D acceleration for my on-board Trident Cyberblade (VIA > PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What > do I have to program in order to get this done? You would need to write - Locking hooks for the X server driver for the trident - A kernel module to supervise the access to the video chip and remove unsafe commands - A 3D graphics driver library for MESA A few tiny starting points exist in the form of some bad documentation for the cyberblade and some very early code for an old MESA that was written by Alan Hourihane and then abandoned before it even drew triangles. It depends what your interests are. If you want to master 3D graphics driver writing and have six months to spare you can have great fun. If you just want a VIA EPIA with working 3D support then the newer chipset (VIA CLE266) DRI is very close to working and you might want to just upgrade hardware and join that effort ? --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 2.6.10-rc3 1/4] agpgart: allow multiple backends to be initialized
On Gwe, 2004-12-17 at 20:55, Mike Werner wrote: > [2/4] Run Lindent on generic.c Please don't mix reformatting with oither submissions, especially as Dave Jones is parallel working on and submitting patches for the various cache/tlb flush violations in the current code that will overlap such a reformatting. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI backwards compatibility problem from X.Org 6.8.0 onwards
Does this not break compatibility with 6.8.0/6.8.1 - that seems at least as big a problem as the breakage from 6.7 because it will prevent anyone stuck with a 6.8.* driver from updating to get security fixes ? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 code in Xorg
On Sul, 2004-12-12 at 18:53, Eric Anholt wrote: > An all-fallback DRI driver is slower than software indirect GLX, if I > remember right. If your fallback driver has the frame buffer mapped and allocates the backbuffer in main memory it ought to give good performance. A naÃve implementation of DRI fallbacks puts the buffer in video ram and that is a disaster. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
On Mer, 2004-12-01 at 12:19, Thomas HellstrÃm wrote: > Actually, I've been running with a 512Kb userspace / kernel buffer, and > I've not seen any noticable drop in performance, but I'm not sure that the > submissions actually will be that large with the programs I've tested. Might be worth finding the size needed - remembering a 512K buffer can be verified and copied in 32K chunks anyway. > If the perfomance drop I experience with running the verifier on AGP > memory is due to the fact that none of it is previously cached or that the > processor cannot cache WC memory lines while reading? If it is due to the > latter then we should be OK with large cacheable buffers. Otherwise we > will run into trouble when the buffer does not fit in the cache. AGP space is uncached. We could pull the pages out of AGP, write to them and put them back but we don't really support that right now. As a result all I/O to AGP pages is strictly synchronous. Pulling stuff from cachable memory and verifying it will prefetch lines from memory on the later processors (and you can also hint this with the prefetch(address) call in the kernel (prefetch about 320 bytes ahead is normally right). I'd expect the user pages are already in L2 cache anyway from when Mesa wrote the bits. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
On Maw, 2004-11-30 at 20:09, Thomas HellstrÃm wrote: > Textures in AGP memory is currently not allowed, but they are disabled > in the Mesa driver as well, for some reason. If they are allowed in the > future, Texture address checks probably have to be implemented but that > should be a minor task. I certainly turned them off because they were crashing my box in the original "hey it sort of works" codebase. I don't know if its that or if someone did more work on it later. > The verifier is reasonably fast. It lowers the glxgears frame-rate a > percent or two. However if it operates directly on AGP memory, it's a > _real_ performance killer. So the userspace command buffer should be > copied to kernel (static) system memory, checked and then copied again > to the AGP ring-buffer. That should be fine if the command buffers are not too large (< 64K or so) because they will be cached for the two passes. > Not all 3D functionality is in, but it is a start and it apparently > works ok with the current Mesa unichrome driver. I've tested glxgears, > chromium, tuxracer and the GL xscreensavers. I'd rather it under than overpermitted things too. > Comments are appreciated, particularly on the security assumptions and > whether something doesn't fit well into the DRM coding style. Only real comment is that it would be better if the tables were pre-initialized. gcc has some extensions for just specifying bits of an array that might do this. Thats really it. Looks good --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (xfree86) dri kernel modules (sis-6326)
On Sul, 2004-11-28 at 23:36, [EMAIL PROTECTED] wrote: > Hello, > > I would like to know if a dri kernel module for the sis-6326 video card > is in development or if a version is available for download? I am using > Fedora Core 1. I got it vaguely working but never had time to debug textures or some strange Z buffer problems. Its such a slower card however nowdays .. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: via.o build problem with 2.6.10-rc2-mm2
On Mer, 2004-11-24 at 02:28, Dave Airlie wrote: > That is due to the new remap_pfn_range stuff, I'm not sure we can put > checks for it into our CVS tree, as -mm trees don't have different > KERNEL_VERSION than Linus trees, you could try building the linux-core > tree rather than the linux-2.6 tree... > > If that stuff is in Linus's tree we need to put the checks in but not > until then... Its in 10rc as well. The change fixes various things like remapping pages high up. Also btw heading this way and it broke AGP and seems to break DRI is Linux x86 using the Xen paravirtualizer. This correctly implements virt_to_bus/dma_alloc and friends but being virt_to_bus/virt_to_phys are no longer randomly the same as they are on generic x86, and two adjacent kernel virtual addresses may not have the adjacent bus addresses. Right now i810 with acceleration explodes in this configuration. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri triple buffering?
On Iau, 2004-11-18 at 23:22, Ian Romanick wrote: > The problem with that is the X-server will have to render everything 3 > times. That's going to suck. You'll have some of the same problems > that Jacek had with his stereo patch. No the X server needs to render everything (expensive bit) _once_. It needs to blit it to the other surfaces (cheap) once per surface. Thats a very important distinction. Especially as the shadowfb code just happens to include all the needed rectangle list stuff... Alan --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Determining if a connection is local
On Iau, 2004-10-21 at 16:49, Thomas HellstrÃm wrote: > architecture-independent library should be able to determine whether the > connection is local or not. Any hints on how to do best do this without > using drm? Try DRM first and see if it fails. There really isn't much else you can do - "local" connections to X include ssh forwarding and proxies 8( --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
On Maw, 2004-10-12 at 01:14, Dave Airlie wrote: > application so it could modify them after validation if it was sufficently > sneaky enough... for the mach64 the idea was to allocate a pool of private > buffers using pci interfaces and use those to pass command streams after > verification.. the user app wouldn't be able to map these... Unless the data set is very large this is the right answer - just copy them. You can revoke pages but that is messy and involves cross CPU calls so sucks on SMP or HT machines. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
On Llu, 2004-10-11 at 09:42, Thomas HellstrÃm wrote: > So what is your actual suggestion? > Export read-write as default or, as proposed, export read-write when > "AllowInsecureDRI" is enabled in the X server config? AllowInsecureDRI is less secure than forcing users to run things as root or fix the code. And we want that code in kernel and causing pain in order to make people fix it 8) If I setuid an app then it depends if that one app is trojanned. If I have AllowInsecureDRI then any trojanned or hostile app gets you. What I think you do want to avoid would be something like "DRI is faster as root", which sends all the wrong signals. Alan --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization / AGP
On Iau, 2004-10-07 at 15:40, Ville SyrjÃlà wrote: > Why can't we make AGP memory cached? Wouldn't it be enought to flush the > caches at some critical points? Possibly although it is not trivial to see how we get that right, especially with the 4Mb kernel maps. The x86 processor cannot handle a page being mapped both cached and uncached at once. Even more excitingly this includes implicit suprise caching by the CPU (speculative and hardware prefetch). This is more a TLB than cache issue. > I was playing around with DirectFB and AGP some years ago and enabling > write-back caching didn't seem to have any side effects. Without caching > AGP is almost as bad as video memory for sw fallbacks. It would be nice to get cacheable AGP but that means some fairly hairy things especially on SMP systems. Pulling a page out of AGP doing a TLB shootdown for it, and then putting it back after wbinvd might work. One to talk to the processor people about. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Via DRM security status (WAS Re: Kernel Oopses in recent DRMs)
On Iau, 2004-10-07 at 00:41, Thomas Hellstrom wrote:
> One option is to do command verification for 2D commands only, and
> tighten up the DDX. In this way the DRM could go into the kernel and be
> usable with XvMC. OpenGL possibly as root, until someone has the time to
> fix up the 3D driver and implement a full command verification.
This would be good, espcially if the verifier shipped looked
something like
verify_command_queue()
{
/* A volunteer should write this to allow non root use */
...
}
It will get the code exposure and its a good policy for future drivers
that may initially need similar work.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization
> Note that there's some code in there already which uses the blitter to copy > from framebuffer to agp memory, though it tries to implement the entire > readpixels() operation rather than being a useful low-level operation. AGP memory is hostside uncached (CPU limitations on x86 for one) which means it is better (swap PCI for DDR ram bus latencies is good) but still benefits from the treatment. Alan. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization
On Mer, 2004-10-06 at 22:02, Ian Romanick wrote: > Here's my question. Is there any way to "trick" it into doing > back-to-back reads as a single PCI transfer? So, if I did something like: Not that anyone has found. I'm not sure PCI even really allows it except for prefetchable memory. Except of course DMA - so the DMA for radeon announcement seems ideal for Mesa here. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization
On Mer, 2004-10-06 at 19:36, Ian Romanick wrote: > from video RAM to system RAM. It has to convert the pixel data from its > native, on-card format to RGBA. In the case of my patch, it > converts from BGRA to RGBA while doing the copy. That's why it needs > the SSE2 shift instructions. >From the data Soreen posted it seems to come down to "how many bytes can you pull at once", the rest is noise to the PCI latency. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization
On Mer, 2004-10-06 at 16:56, Dieter NÃtzel wrote: > What about MMX2, 3DNow, 3DNow2 (pro), SSE (1)? > > It would be nice if we have this like MPlayer: Soreen wrote a set of routines for this that are in Xorg 6.8.* and optimise the readback of video memory for render operations - naturally enough they include the speed ups for readback of videoram. DMA is still a better option - being able to DMA a tile to main memory for fixup and DMA back.. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRM and fbdev
On Sul, 2004-10-03 at 23:42, Jon Smirl wrote: > Is there are device driver level interface defined for controlling > tuners? Both at the Xv and the kernel level yes. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRM and fbdev
On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote: > In particular, I can contribute the code that does Framebuffer->System Ram > transfers over PCI/AGP. It is currently GPL licensed, but there is no > problem if BSD folks want it too. This will do *wonders* to X render performance if used properly on those cards we can't do render in hardware. > This is also potentially useful for any Mesa functions that want to > transfer data back from video RAM - using plain reads for this is really slow. Agreed - and Mesa tends to skip even tricks like SSE2 that can quadruple read performance. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Software emulation of shaders.. sw-shader
On Sad, 2004-10-02 at 22:43, Adam Jackson wrote:
> > That looks very cool. I hope someone copies the code into mesa.
>
> I hope they don't, Mesa is BSD now and according to their sf project page
> sw-shader is {L,}GPL:
>
> http://sourceforge.net/projects/sw-shader
LGPL is fine for most things. It would depend how the Mesa and X folks
feel but it doesn't "leak" into the licensing of other code which is the
usual concern. It's also the kind of thing where you could (and you
_would_) want to have it only as an option. Mesa runs on a lot more
platforms than swshader, and I don't see swshader for PPC64 being a
trivial port 8)
Alan
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and vt switching?
On Iau, 2004-09-30 at 13:56, Keith Whitwell wrote: > > Looking in the i810 driver, it seems like the ringbuffer is flushed and > > disabled until the X server calls EnterVT again, and AGP memory is > > unbound. How is the client generally notified about this? > > The server holds the hw lock until the VT comes back. With the client still having access to the unbound AGP pages as AGP side addresses ? --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Mer, 2004-09-29 at 22:52, Felix KÃhling wrote: > Module Size Used by > savage 3520 0 > drm62500 3 savage > > Is it normal that the savage module looks unused? looks like a bug. If the drm layer provides the file_operations for the device node then the locking done automatically locks the wrong module. Thats easy to fix with try_module_get() and module_put() --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Mer, 2004-09-29 at 13:37, Christoph Hellwig wrote: > - once we have Alan's idea of the graphics core implemented drm_init() >should go awaw Last I heard Dave Airlie had that working having fixed my bugs. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
On Sad, 2004-09-25 at 04:41, Patrick McFarland wrote: > Not to sound ignorant, but isn't that a bug in the > mobo/bios/chipset/processors? That shouldn't even be possible, should > it? (And if it 'is', shouldn't Linux disable SSE usage on both > processors?) You can mix PII and PIII processors in a system and get that sort of a result. The kernel correctly handles this for its own use, but user space apps aren't always smart enough. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
On Iau, 2004-09-23 at 17:21, Philipp Klaus Krause wrote: > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4D4E5A16 > Function=(null)+0x4D4E5A16 Looks like a buffer overrun or memory corruption. Are you trying to use mesa very threaded ?[at least 0x4D4E5A16 looks like text...] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
On Iau, 2004-09-23 at 17:22, Ian Romanick wrote: > The folks on #freedesktop suggested parsing cpuinfo, and I wrote some > simple code to do that. Are you saying that, if CPUID returns the SSE > bit set and we're on a 2.4 or later kernel, we're good to go? That > would make me very happy because we already test the CPUID bit, and DRI > isn't supported on 2.2. :) Should do. There is a corner case of SMP with only one CPU having SSE but thats already broken in Mesa and many other packages. The more thorough case is you use /dev/cpu/%d/cpuid to check the CPUid on each processor but I'm not sure thats neccessary in reality --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
