Re: Move lists to freedesktop.org?
On Thu, Apr 8, 2010 at 16:37, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 8 Apr 2010 18:38:03 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul bri...@vmware.com wrote: Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest mode, etc. -Brian Are there plans to move dri-devel as well? Yeah, I'm just getting the info for that now. But I don't think we have subscriber lists, so everyone will have to re-subscribe to the new list. I'll send out a note to dri-devel when it's all set. You can get the subscriber list at: http://lists.freedesktop.org/mailman/listinfo/dri-devel Stephane -- Download Intel#174; 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, Mar 4, 2010 at 23:44, Ingo Molnar mi...@elte.hu wrote: * Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful ?- limits the developer base ?- limits the tester base ?- wastes time and effort. (fewer developers/testers means that while _this_ ? feature was easier to add, all your _future_ features will be a bit harder ? to do. It compounds up.) ?- so it hurts even the very developer who is most convinced that this was the ? right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. - distros just try to get the latest and most capable but still stable version. Desperately so. Often they will create a version mix that was never tested by developers in that form. They'll expose users to ABI combinations that were never really intended. They have trouble bootstrapping and stabilizing those essentially random combinations and then have trouble applying stability and security fixes. The thing is, if development has such characteristics then it's pretty clearly not 3-4 separate projects but _one_ abstract project. [*] So the 'exploding test matrix' is simply the result of: creating ABIs between 3-4 _artificial components of the same project_ and then going through developer hell living with that mistake. [**] It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. Yes that is exactly the problem we are facing. And you know what? All graphic driver devs agree on that, but there is no obvious solution. Here are the interfaces which are part of this problem: - drm interface (drm wrappers as seen from the driver, drm ioctls from the user space) - X.Org acceleration interface (EXA and friends as seen from the driver, XRender and friends as seen from the apps) - Mesa interface (Gallium or mesa driver interface from the driver, OpenGL seen from the app) Any solution will involve merging two or more components together to remove interfaces, so lets observe pairwise what could be merged and the drawbacks: - Merge DRM and Mesa drivers. Technically we could do this, but then what happens when a new OpenGL version/feature comes around? Yes, we get a new mesa interface. So we're exchanging one interface for another here. No gain. - Merge DDX And DRM driver. Same problem as before, whenever 2D interfaces changes, we have to update the DDX anyway. Again, no gain in sight. - Merge Mesa and DDX drivers. This makes sense, and this is where gallium is going by providing 2D and GL acceleration on top of a single, common gallium driver. So yes, I have hopes that this one will happen eventually, at least on non-intel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 12:07, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? The thing is, I violently disagree with your basic premise. The way things are done now, that developer base actually just makes things _harder_ for themselves. They may not be aware that they do so, and they may _think_ that it's easier to just ignore versioning, but they are wrong. And I say that from personal experience. Doing incompatible changes in any code base makes everything harder. It results in users staying on old versions that you _know_ you don't want to support, but because of the incompatible change, they can't sanely upgrade. Seriously. So I bet we could do that wrapper nouveau.so that literally just does the get version, and dlopen the _real_ nouveau-version.so. Quite frankly, I don't know the XAA interfaces (or whatever they are in X these days), but somebody who does know them should be able to cook up such a wrapper in five minutes (and then spend a day testing it because of some silly bug, but whatever..) Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? No. It makes our lives much more complicated. I've worked on the radeon driver before and about half my time was spent just checking compatibility with multiple kernel/user space combinations. You have to handle all possible combinations of DRM+DDX+Mesa drivers, and that gets hairy real quick. Then for nouveau I decided not to bother until interfaces were stable enough, and I think all developers agree on that. I suggest you think about the do not break user space interfaces principle from a graphics developer point of view and what that means for the user space code. For example, you could take a look at the radeon DDX or Mesa drivers, which do implement compatibility. In the long run this leads to little gems like this: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r200/r200_state.c#n2148 Obviously even though there is some form of compatibility, not all user space/kernel combinations are tested. In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually Stephane -- Download Intel#174; 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, Mar 4, 2010 at 15:03, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. So unmerge it. That's what I told people I can do (I'd just revert that commit). I can do that. But it's not very productive, is it? What about the people who _do_ want to run the rawhide tree? Seriously - what's wrong with my suggestion to just version things properly? What's wrong with _fixing_ a stupid technical problem? What's wrong with people that you can't see that there are actual _solutions_ to the f*cking mess that is the current situation? I can solve it for my own use, and I already stated so. But while kernel developers should be scratching their own itches, a kernel developer that can't see past his own small sandbox is pretty damn worthless. We do need to fix this - and I'm bringing it up and complaining about it, because the nouveau people have _not_ done anything remotely sane. Again, if we thought the DRM interfaces were good to begin with, we'd have submitted the driver for inclusion. But that's not the case so the we didn't submit the DRM. Whoever did gets to cope with the issues. Good luck, Stephane -- Download Intel#174; 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: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, Mar 4, 2010 at 15:09, Brian Paul bri...@vmware.com wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. Also I've been banned from posting to the lists at sf.net in the past because my smtp server was in their (wrong) RBLs. So I'm happy if the lists are moving away. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? No, you still have the mailman interface to handle all this. Stephane -- Download Intel#174; 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: 3D OpenGL applications eat CPU ressources
On Sat, Feb 6, 2010 at 11:47, Émeric Maschino emeric.masch...@gmail.com wrote: 2010/2/4 Jerome Glisse gli...@freedesktop.org: IIRC old radeon drm doesn't have any thing to dump GPU command stream. Look at http://www.x.org/docs/AMD/R5xx_Acceleration_v1.4.pdf to see what radeon GPU stream command looks like (packet pm4 stuff). Note that dump GPU command stream can quickly eat Gigs of data and finding what is causing the lockup is then very cumberstone especialy as in your case it sounds like it's a timing issue. You might want to force your card into pci mode to see if it's agp related. Yep, setting Option BusType PCI in /etc/X11/xorg.conf prevents from GPU lockup. A a side note, strace glxinfo and strace glxgears still give me read() errors on /tmp/.X11-unix/X0, so they're probably not related to GPU lockup. Anyway, I don't know whether this is due to PCI mode or not, but OpenGL performances, although there's no more GPU lockup, are poor. And serious OpenGL applications, as simulated by the SPECviewperf test suite, have very irregular frame rates. If I'm not mistaken, the BusType option is specific to the radeon driver (or maybe other drivers too)? I mean, it's not a X.org wide configuration option, isn't it? This would thus narrow my investigation path to the AGP code of the radeon driver, right? From what I recall, all the ia64 AGP chipsets (well the zx1 and the 460) have to be run: - without side band adressing - without fast writes - at 4x speed otherwise they're unstable. I think by default agpgart puts them at AGP 1x with fast writes... Stephane -- 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: 3D OpenGL applications eat CPU ressources
On Mon, Feb 1, 2010 at 13:17, Émeric Maschino emeric.masch...@gmail.com wrote:
2010/1/31 Jerome Glisse gli...@freedesktop.org:
snip
Eventually, strace log is flooded with
ioctl(4, 0xc0106451, 0x6fd530f8) = 0
roughly at the time the CPU charge increases. This is consistent with
what is recorded in syslog:
Jan 29 21:16:03 longspeak kernel: [ 318.611783] [drm:drm_ioctl],
pid=2426, cmd=0xc0106451, nr=0x51, dev 0xe200, auth=1
Jan 29 21:16:03 longspeak kernel: [ 318.611789]
[drm:radeon_cp_getparam], pid=2426
repeated several tens of thousands times where 2426 is glxgears PID.
snip
You are hitting GPU lockup which traduce by userspace keep
trying the same ioctl over and over again which completely
eat all CPU.
Thank you for clarifying. Does GPU lockup mean that this problem is
specific to my current hardware configuration? If I try an other
graphics adapter (choices are scarce on ia64), is it possible that I
don't experience GPU lockup at all or a different one?
There is no easy way to debug GPU lockup and no way at
all than by staring a GPU command stream or making wild
guess and testing things randomly.
Just to clarify: I imagine that a GPU command stream is specific to a
given GPU/driver. Does it mean that the commands sent to the GPU are
not the sames on different Linux platforms (e.g. ia64/r300 vs.
x86/r300)?
About GPU command, is this something I can read in the various
logfiles? Is there some kind of command generator to send a specific
command or command stream to the GPU in order to help determine which
one is the faulty one?
I don't know if these are the command sent to the GPU but, looking
again at the strace glxgears output I've recorded, I'm getting:
futex(0x6fd53420,
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
2004d1e8) = -1 EAGAIN (Resource temporarily unavailable)
and numerous
read(3, 0x600093e4, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
Should the return value of read() be equal to the number of blocks (I
imagine) passed as the third argument? In this case, before getting
EAGAIN error when trying to read blocks, I'm getting this following
sequence that seem to shift something:
writev(3, [{b\0\5\0\f\0\0\0BIG-REQUESTS, 20}], 1) = 20
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, \1\0\1\0\0\0\0\0\1\216\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0,
4096) = 32
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{\216\0\1\0, 4}], 1) = 4
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, \1\0\2\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0,
4096) = 32
read(3, 0x600093e4, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
From there, all subsequent pair of read() calls fail.
By contrast, in the (old) strace glxgears excerpt posted here
(http://ubuntuforums.org/showthread.php?t=75007), the read calls seem
to always succeed.
Could this be a starting point or not at all?
If an ia64 machine lockups, it will usually store an MCA telling you
about why it locked/where in the code this happened.
This is how I got ia64 DRI going a bunch of years ago. For what it's
worth, most of the bugs were:
- pci resources casted to 32 bit in the DRM
- some 32 bit adresses but that got fixed as a side effect of us
having x86_64 supported now
- large (32 or 64 bit) writes to I/O areas (should be all 8 bit, the
ia64 crashes otherwise) either from the kernel or from user space
Really to track those the MCA errors proved extremely useful. Usually
they carry a pci adress and all...
Stephane
--
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: [git pull] drm
On Fri, Dec 11, 2009 at 00:58, Alan Cox a...@lxorguk.ukuu.org.uk wrote: 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. So what, if someone outside RedHat is ok to sign it off, it can go into staging? If it's that simple I don't mind signing it off (including the dubious bits), I can take the blame if that helps things move forward. Stephane -- 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 nouveau pony for Xmas.
2009/12/12 Dave Airlie airl...@gmail.com: 2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: I did git log on the nouveau kernel tree nouveau dir with sort and uniq, I'm not sure where else I needed to trawl to get anymore ppl who have contributed to the KMS driver. I'm sure ppl contributed to X.org/Mesa drivers but this isn't the place for them. Also all copyright should be intact. The problem is that when you moved from the drm to the linux tree, you killed the whole history and the authors along. But we can add an author lists to the code subdir if you like, if someone compiles the complete list of ppl who have added code to the kernel driver. That would indeed be the proper thing to do. Stephane -- 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 nouveau pony for Xmas.
On Sat, Dec 12, 2009 at 00:27, Stephane Marchesin stephane.marche...@gmail.com wrote: 2009/12/12 Dave Airlie airl...@gmail.com: 2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: I did git log on the nouveau kernel tree nouveau dir with sort and uniq, I'm not sure where else I needed to trawl to get anymore ppl who have contributed to the KMS driver. I'm sure ppl contributed to X.org/Mesa drivers but this isn't the place for them. Also all copyright should be intact. The problem is that when you moved from the drm to the linux tree, you killed the whole history and the authors along. But we can add an author lists to the code subdir if you like, if someone compiles the complete list of ppl who have added code to the kernel driver. That would indeed be the proper thing to do. Ok, as you requested here is a proper list of actual authors: Arthur Huillet arthur.huil...@free.fr Anssi Hannula anssi.hann...@iki.fi Ben Skeggs bske...@redhat.com B. Rathmann koala...@users.sourceforge.net Danny Tholen moondr...@gmail.com Dave Airlie airl...@redhat.com Francisco Jerez curroje...@riseup.net Jeremy Kolb jk...@brandeis.edu Maarten Maathuis madman2...@gmail.com Marcin Kościelnicki koria...@0x04.net Matthew Garrett m...@redhat.com Matthieu Castet castet.matth...@free.fr Matt Parnell mparn...@gmail.com Maurice van der Pot griffo...@kfk4ever.com Patrice Mandin patman...@gmail.com Pekka Paalanen p...@iki.fi Stephane Marchesin marche...@icps.u-strasbg.fr Stuart Bennett stu...@freedesktop.org Xavier Chantry shinin...@gmail.com As far as I can recall, this list is complete. Stephane -- 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 nouveau pony for Xmas.
/nv50_display.c create mode 100644 drivers/gpu/drm/nouveau/nv50_display.h create mode 100644 drivers/gpu/drm/nouveau/nv50_evo.h create mode 100644 drivers/gpu/drm/nouveau/nv50_fbcon.c create mode 100644 drivers/gpu/drm/nouveau/nv50_fifo.c create mode 100644 drivers/gpu/drm/nouveau/nv50_graph.c create mode 100644 drivers/gpu/drm/nouveau/nv50_instmem.c create mode 100644 drivers/gpu/drm/nouveau/nv50_mc.c create mode 100644 drivers/gpu/drm/nouveau/nv50_sor.c create mode 100644 drivers/gpu/drm/nouveau/nvreg.h create mode 100644 include/drm/i2c/ch7006.h create mode 100644 include/drm/nouveau_drm.h commit 6ee738610f41b59733f63718f0bdbcba7d3a3f12 Author: Ben Skeggs bske...@redhat.com Date: Fri Dec 11 19:24:15 2009 +1000 drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04-g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula anssi.hann...@iki.fi Ben Skeggs bske...@redhat.com Francisco Jerez curroje...@riseup.net Maarten Maathuis madman2...@gmail.com Marcin Kościelnicki koria...@0x04.net Matthew Garrett m...@redhat.com Matt Parnell mparn...@gmail.com Patrice Mandin patman...@gmail.com Pekka Paalanen p...@iki.fi Xavier Chantry shinin...@gmail.com along with project founder Stephane Marchesin marche...@icps.u-strasbg.fr Btw could we get proper developer credit here? I think 3/4 of the people who wrote the code are missing here. Stephane -- 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
On Thu, Dec 10, 2009 at 19:42, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 10 Dec 2009, Maarten Maathuis wrote: You assume that Red Hat has full control over the project, which i don't think is the case. The reason it isn't in staging yet (as far as i know) is because of some questions over the copyright of some (essential) microcode. Either the question needs to be answered, or it has to be reverse engineered to the point that it's possible to generate it. I think people are just making up excuses, as evidenced by the fact that you're quoting a different excuse than I've heard before. The fact is, if there are license questions, then Fedora had better not be distributing the code either. And they clearly are. And don't tell me about full control. There's absolutely full control over it being included or not. When I brought this up at the kernel summit, there were various other random excuses. I think one of them was that it wasn't part of an official Fedora release (which is sure as hell not true at least as of Fedora 12). 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. The most common excuse is the oh, but it might change crap. But that's not even a very good excuse to start with, and it's what staging is for anyway. Somebody even made the crazy comment that but Fedora isn't a real distribution, so it doesn't need to follow the rules everybody agreed to several _years_ ago wrt merging stuff to mainline. I _think_ that last one was meant as a joke. But it's damn hard to tell, because the ones that are apparently sincere are equally crazy. People just seem to make up total crap to make excuses for something that everybody knows is wrong. I'm not sure why people are arguing so much over this, given that no nouveau devs were at the kernel summit, and we only heard rumours afterwards that there were complaints about us not being ready for merging. If you have issues to raise about nouveau, please raise them on the nouveau, mesa or dri lists, at least some time before starting to complain. I must say I didn't think such a big issue was going on here, that's the problem with rumours. Stephane (nouveau founder). -- 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
2009/12/10 Alan Cox a...@lxorguk.ukuu.org.uk: 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 ? There is a (actually multiple for different card generations) stub of the firmware visible in the binary, but it can't be used as-is, it has to be tailored to each card. Stephane -- 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: RFC: libdrm repo
2009/11/17 Kristian Høgsberg k...@bitplanet.net: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. For the record, I don't think my concerns were adressed. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
[oops, with reply-all this time] On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). Btw the kernel releases every 3 months. That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. I don't see big advantages to packaging it with the kernel, mainly disadvantages. I don't think it'll get wider testing if it's in the kernel, and I don't think compatibility will be easier to maintain. FWIW, you gave me the opposite argument when you decided that DRM development should happen in the kernel. Back then you used to say that we'd get more testers that way. Which one should I believe? There's a big downside too, since it makes packaging much harder. Distros typically stick with one kernel for a relatively long time, but if they want to pick up a libdrm fix unrelated to a new DRM interface (like the one Remi pointed out) they'll have to grab a recent kernel, extract libdrm, and make sure it works with their current kernel (which may involve some extra work if new DRM interfaces have gone in too). Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, Nov 9, 2009 at 11:51, Rémi Cardona r...@gentoo.org wrote: Le 09/11/2009 00:14, Robert Noland a écrit : There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel. Absolutely. In fact, one of the biggest Intel performance wins lately was in a libdrm change [1] that had absolutely nothing to do with the kernel per se. Not having to force a new kernel down our users throat was very welcome. But then it sees little testing. If you ship together with the kernel, you get the rc test phases and all... Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, Nov 9, 2009 at 17:42, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime.People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. I don't care about the transition. I care about the long term. Replace 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user get his libdrm at that time? Well, once libdrm is with the kernel, you get libdrm ... with the kernel. What's unclear in what I explained? And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing
Re: RFC: libdrm repo
2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. Now I don't get it. You say versioning libdrm headers is the right thing? Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime. People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. If the only reason not to merge the libdrm into the kernel tree is because you have a difficult time finding a libdrm for old kernels (and only during the transition), well I'd say that means there's no real problem here. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/9/1 Keith Whitwell kei...@vmware.com: On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? The hw does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? I'm coming to this late, but if the only difference between hw-specific and hw-independent interfaces is which formats are supported, that surely shouldn't be too hard to abstract? Just have an enum which gets expanded with new format names and query for supported formats in the API. As I said, if my hw overlay only does YUY2 and I want to expose YV12/I420 (because that's what everyone wants), I get to do the conversion myself. Now in the old case I could do it in the driver, but now you can either: - remove it and players stop using the overlay altogether (because few players will convert YV12 to YUY2 themselves) or - do a conversion layer between the formats which gets annoying fast So in the end I will still write a card-specific ioctl. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/8/31 Thomas Hellström tho...@shipmail.org: Daniel Vetter wrote: ... In conclusion I don't think a common ioctl is worth it. But sharing some code and infrastructure on the kernel side is certainly possible, if someone implements overlay support for another chipset. But I don't really count on that, because at least radeon has textured video for all it's chips. I understand your concerns about the new X architecture where everything is composited, and I admit I haven't looked through your patch in detail. However, we'll _probably_ need to add overlay support to the Xorg gallium + KMS state-tracker shortly, and if so, with that a generic KMS interface that is sufficient to implement a simple Xv overlay adaptor with KMS. Given the fact that Xv and various virtual device overlay support implementations exist, I assume there *must* be a way to do this generically. Perhaps not in the interest of sharing kernel code, but in the interest of a single user-space interface and a single user-space implementation supporting multiple hardware drivers. I've looked at this before, and you basically end up adding something similar to the Xv API in the kernel (for handling pixel formats, size pitch limitations, vsyncing, ...). I'm not sure it's worth it, especially since overlays are doomed. Of course overlays are faster than textured/blitter video so it's worth implementing, but I'd keep this as a device-specific ioctl. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything. IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? That said, if someone achieves a generic ioctl that can do this, I have nothing against it. It's just that it seems to be a lot of work for little benefit (IMO). Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ 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
You obviously got all this completely wrong. I avoid writing closed source drivers whenever I can, I'm not whining and I'm not trying to push any of them. The code VIA is trying to submit has not been written by me nor anybody I know. All VIA code I and the companies I've worked for has written is open-sourced and contributed to the Openchrome / mesa / drm project. The point I'm trying to make is the following: 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! I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about? * Second example, what is the policy if we find security holes in the DRM for a closed user-space afterwards? This breaks the initial promise of security, does that get the driver removed then? Or what if the promise is pending updated documentation that never arrives? * Third example, what if down the line we need changes in the DRM that require updating all DRM modules. Do we (we as in DRM developers) touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking the code (since we don't test with proprietary modules)? Or do we let the Chrome9 files as-is, keeping the old DRM infrastructure and therefore add more and more DRM cruft? In my opinion, accepting GPL'ed DRM modules that support binary user space components is like opening pandora's box. Stephane -- 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
2009/7/20 Thomas Hellström tho...@shipmail.org: Stephane, Some comments on how these things has been handled / could be handled. I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about? If there is a serious OS project, I'd start a new DRM driver. That's sort of what may happen with openChrome vs via.. Well, for user space, there can be as many drivers as you want for a given device. But the DRM policy always was one driver per hardware so as to avoid confusing people, so what you're proposing is in fact not possible. In that case, this would even deter a fully open source driver as it would have to keep the same interface as some (possibly unsupported) driver. * Second example, what is the policy if we find security holes in the DRM for a closed user-space afterwards? This breaks the initial promise of security, does that get the driver removed then? Or what if the promise is pending updated documentation that never arrives? I'd say the DRM driver gets disabled unless fixed. How would we handle that problem today with, for example, the SiS driver? If no one can fix it it gets killed, yes. I would expect this to happen pretty quickly in fact, in which case the driver merge/problem found/driver removal cycle requires more work than it's worth. * Third example, what if down the line we need changes in the DRM that require updating all DRM modules. Do we (we as in DRM developers) touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking the code (since we don't test with proprietary modules)? Or do we let the Chrome9 files as-is, keeping the old DRM infrastructure and therefore add more and more DRM cruft? Again, this has been done quite commonly in the past and was easier to get right with the old drm.git testing ground. Same issue with unmaintained drivers with OS user-space. Who has actually tested all the drivers when making such a change? I certainly haven't. The change was left for testing for a while in drm.git before Dave moved it upstream. Well, some of us want to be thorough when doing invasive changes, untestable code would prevent such changes (and then we get more of the DRM cruft as a result). And yes, if people do not cooperate on all drivers, this leads to issues in the code. At this point it's not a matter of open source vs closed, but a problem of cooperation. Stephane -- 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/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Fri, Jul 17, 2009 at 15:23, Keith Whitwellkei...@vmware.com wrote: Maybe VIA can provide some userspace code without putting together an entire driver. A handful of standalone programs that exercise the interface would help evaluate the interfaces and might be sufficient to serve as guide to someone wanting to use this module. A handful would include: -- draw a triangle -- draw a textured triangle -- draw a triangle using indexed vertices -- some sort of occlusion query At least then there would be some concrete examples of this in use so that an interested party wouldn't later have to work from scratch. Well, given that you'd be (first and foremost, IMO) trying to evaluate the security of the DRM module, this would also require some code demonstrating DMA transfers and texturing over AGP/PCI... In any case, a similar situation occured before (open DRM driver but proprietary user space bits): http://thread.gmane.org/gmane.linux.kernel/809146 Stephane -- 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: [RFC][PATCH] drm/radeon/kms: add initial colortiling support.
On Thu, Jun 25, 2009 at 09:46, Jerome Glissegli...@freedesktop.org wrote: On Wed, 2009-06-24 at 22:32 +0200, Roland Scheidegger wrote: On 24.06.2009 20:17, Jerome Glisse wrote: I think we should let user ask at gem map ioctl time if userspace wants an surface backed mapping or not, and gem map will reply with a success or failure. So if object is in vram and there is a surface reg available it will succeed, if object is in system ram it will report to userspace that there is not automatic untiling and that userspace is on its own to untile the buffer. For the X server that the front buffer is mapped first and never unmapped, it should get a surface (assuming no other process already stole all the surface). For pixmap i think be better of not using tiling for time being (or macro tiling only benchmark below). Mesa, map/unmap things and should be able to untile on its own for front/zbuffer (we need to add texture but i am not sure it's worth it, see benchmark below). I don't see benchmark with texture tiling below... It definitely made some difference though when I implemented (and measured...) this, though I never really worried that much about tiled compressed textures, not sure micro tiled is even possible (and would make sense) but macro tiled certainly should be (but IIRC I tried to measure it and it didn't make much of a difference on r200 but it could have changed with newer chips). That said, don't forget that the performance improvement this gives is chip specific, generally giving more improvement with newer chips. IIRC you definitely don't want to micro tile the front buffer pre-r300. Roland Yeah i loose texture benchmark but it was very small 1-2% on quake3 but maybe quake3 isn't asking for much texture filtering, assuming filtering is the process which benefit from tiled texture. IIRC the microtiling mode will only benefit the exotic filtering modes (anisotropic for example). Did you try this? Stephane -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Round size of mappings in drmAddMap ioctl
On Mon, May 18, 2009 at 03:11, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Currently, userspace fails to obtain the SAREA mapping on some platforms because they pass SAREA_MAX to drmAddMap without aligning it to the page size. This breaks for example on PowerPC with 64K pages. The way SAREA_MAX is defined with a bunch of ifdef's and duplicated between libdrm and the X server is gross, ultimately it should be retrieved by userspace from the kernel, but in the meantime, we have plenty of existing userspace built with bad values that need to work. The actual SAREA in the kernel is created with an aligned size by the radeon driver (I haven't tested others) so it's purely a userspace problem. This works around it by rounding the requested size in drmAddMap to the page size. There should never be any need to manipulate maps smaller than a page (MMIO regions might but there isn't much we can do about it) and our mmap() calls has enough sanity checks here if the map is actually too small to be mapped. We also only do that fir the ioctl, not the in-kernel call. So, in order to fix a problem with the SAREA you align the map size for all added maps? Sounds bogus to me, especially since the range of possible page sizes is potentially unbounded. IMO the proper thing to do is to fix the drivers when they create the SAREA... Stephane -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] mga: Use request_firmware() to load microcode
Hi, This mga patch replaces a firmware that was split in pieces by functionality and that had comments with a single blob. So IMO it's actually decreasing the quality of the code. Stephane -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 lockup in radeon_cp_texture/radeon_freelist_get
On Thu, Feb 19, 2009 at 15:46, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger srol...@tungstengraphics.com wrote: On 19.02.2009 12:23, Arkadi Shishlov wrote: Roland Scheidegger wrote: I suspect you're hitting a r200 asic bug, which isn't present in rv250 and other r200 family members. There are workarounds in the driver for this (see r200UpdateTextureState), but to my knowledge they are insufficient for two-pass ATI_fragment_shader shaders. There's also a You're right. I changed video card to RV280 9250SE and lockup goes away. Nice picture, a little slower than fglrx, probably due to 9250 being slower than 8500. doom3 is actually a performance mystery to me. On my 9000pro, performance seemed to be similar to fglrx, however using another OS it was vastly faster, and I always wondered how it could be tweaked... Hyperz doesn't seem to help much, neither does the mipmap optimization, yet still somehow it must be possible to make it run much faster. mesa test which last I heard showed errors (progs/tests/afsmultiarb) (you can switch the test between one and two pass shaders). If this is the problem, you could try running doom3 using the arb path I think something like doom3 +seta r_renderer arb might work, however arb path looks ugly (r_renderer defaults to best which will then choose r200 on this card). Yes, its ugly and incorrect, some walls are not opaque but blends over another walls. Oh, that sounds like a bug. Ugly yes but I didn't see that. Unfortunately I don't know how this could be fixed, as documentation for these asic bugs is nonexistent (or at least non-public). If lockup could be reliable reproduced with simple test - like afsmultiarb in fresh X without WM - will it be helpfull to get mmio trace from fglrx and r200 drivers to compare? I think at least some of the asic bugs do not necessarily result in a lockup but also could result in misrendering. Someone might be able to figure out what fglrx does, I guess of particular interest would be the writes to these debug regs (0x2D90 through 0x2DBC). That said, it might not be easy to figure this out completely (could depend on which texture units are enabled in what pass, and depending on filtering on each of those). Or it could even be some completely unrelated bug. In the light of recent progress with AMD's attitude, can't you just ask fglrx guys about R200 bug? R200 is understandably not exactly top priority, and it seemed like the usual docs didn't cover it. Though maybe Alex wants to comment on this. Unfortunately, r200 is so old, it hard to find much information on it anymore. The r200 docs were released under NDA to selected people. So I don't think the r200 docs have completely disappeared off the earh ;) Stephane -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing nv from drm git
On Thu, Jan 29, 2009 at 09:40, Thomas Hellström tho...@shipmail.org wrote: Owain Ainsworth wrote: On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Please do. Done. I'm wondering if we should prune i915 now that it's not developed in drm.git anymore. -0- We should get rid of old TTM as well. I can fix that, but I need to disable everything that uses it, which IIRC includes i915. Right, probably the intel stuff doesn't need to live in drm.git, although I suppose that's a question for the intel guys. What about reorganizing linux-core with a subdirectory for each driver? Yeah I think that would be a good idea, and would make drm.git closer to mainline kernel. Stephane -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing nv from drm git
On Wed, Feb 4, 2009 at 11:14, Thomas Hellström tho...@shipmail.org wrote: Stephane Marchesin wrote: On Thu, Jan 29, 2009 at 09:40, Thomas Hellström tho...@shipmail.org wrote: Owain Ainsworth wrote: On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Please do. Done. I'm wondering if we should prune i915 now that it's not developed in drm.git anymore. -0- We should get rid of old TTM as well. I can fix that, but I need to disable everything that uses it, which IIRC includes i915. Right, probably the intel stuff doesn't need to live in drm.git, although I suppose that's a question for the intel guys. Hmm, I read somewhere in a README that it's no longer maintained in drm.git so it's rather pointless to have it there unless someone Yes in the drm README. backports what's currently in the kernel or drm-next. That doesn't hold through for !Linux I guess, so I think we'd just be pruning it from linux-core. Yeah, also if we go for an organization similar to the linux kernel we are going to move the BSD bits in another folder anyway. Btw another driver that might not like the move is XGI I think, since it also depends on the old TTM ? Stephane -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Removing nv from drm git
Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Stephane -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing nv from drm git
On Thu, Jan 29, 2009 at 02:29, Owain Ainsworth zer...@googlemail.com wrote: On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Please do. I'm wondering if we should prune i915 now that it's not developed in drm.git anymore. Im not sure, as that would put us further from the goal of drm.git and the kernel stuff matching (modulo compatiblity stuff). Stephane -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Nouveau merged into gallium-0.2
Hi, As you might have noticed, nouveau's gallium work has been merged into mesa's gallium-0.2 (yeah I slacked long enough on that). So now nouveau development should happen there (mesa/gallium-0.2). Mesa also gains g3dvl, which is Younes's summer of code work on implementing video decoding on top of gallium. That does not mean nouveau magically became stable overnight, but at least we don't have multiple trees all around. Anyway, if you see something weird or broken, it's probably my fault. You can beat me. Or just tell me :) Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] remove DRM IRQ installation funcs
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED] wrote: The DRM design includes ioctls to allow a userland driver to tell the kernel driver when to register its interrupt handler and on what IRQ. This is a really bad idea for several reasons, and fortunately I don't think any DDX drivers take advantage of the no, use this IRQ aspect of the API (and even if they did the kernel driver would have to ignore it). This patch removes the DRM support for those ioctls, making drivers just register their interrupt handlers at load time. The patch is fairly straightforward but there are still caveats, so each driver will need careful review to make sure that userland drivers don't set up additional state required for proper interrupt handling/enabling. It also means drivers have to map registers at load time; the r128 bits in particular looked funky in that regard so extra eyes there would be appreciated. I've only tested this patch so far on i915, where it's still slightly broken; I was planning on fixing it once I've sync'd some more linux-core changes into drm-next (namely the rest of the vblank-rework code). This patch breaks a couple of drivers. Is this an oversight, or does the new development model mean that we break drivers that are not in linux each time ? Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] remove DRM IRQ installation funcs
On Tue, Aug 26, 2008 at 9:36 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote: On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED] wrote: The DRM design includes ioctls to allow a userland driver to tell the kernel driver when to register its interrupt handler and on what IRQ. This is a really bad idea for several reasons, and fortunately I don't think any DDX drivers take advantage of the no, use this IRQ aspect of the API (and even if they did the kernel driver would have to ignore it). This patch removes the DRM support for those ioctls, making drivers just register their interrupt handlers at load time. The patch is fairly straightforward but there are still caveats, so each driver will need careful review to make sure that userland drivers don't set up additional state required for proper interrupt handling/enabling. It also means drivers have to map registers at load time; the r128 bits in particular looked funky in that regard so extra eyes there would be appreciated. I've only tested this patch so far on i915, where it's still slightly broken; I was planning on fixing it once I've sync'd some more linux-core changes into drm-next (namely the rest of the vblank-rework code). This patch breaks a couple of drivers. Is this an oversight, or does the new development model mean that we break drivers that are not in linux each time ? 1) this is an RFC that hasn't been pushed anywhere yet, so nothing is actually broken by it 2) this patch is against the drm-next Linux tree, so any breakage is limited to the drivers there But I assume you're talking about nouveau? nouveau, mach64, xgi... Does it have any funky requirements wrt IRQ registration? Or would it be relatively easy to move its interrupt handler registration and IRQ setup to the load routine? It is easy, but I'm realizing things might not be as easy for more intrusive changes. I'm merely pointing out that things don't seem to be wokring out when we have a lot of branches and global changes happen. In-development drivers are not fixed, other operating systems are not fixed, in-development features can conflict and so on... It really seems untractable, so it really seems to me need a single place where all the current DRM action happens and the merge to linux from there. Otherwise the open source graphics world will start to lose drivers and platform support. As for the new development model... Things are actually worse than I thought. There are some fairly large differences between linux-core and upstream, some of which have been in linux-core for a long time. It's one thing to have an out-of-tree development process but another entirely to let stuff rot for months years there. It just adds to the already huge set of driver combinations we have to worry about and support... How is doing merges preventing us from working on a single tree ? It's two completely separate problems. So drm-next is all I care about anymore. I'm trying to sync the last couple of years worth of development to that tree so I can start ignoring linux-core entirely. It's just too disconnected from upstream Linux for me to worry about (note that this doesn't mean I don't care about BSD compat; I want to make sure sharing is still reasonably easy, but if anything I'd like the merges to go from drm-next - linux-core rather than the other way around for my development). Ok, so to restate that clearly you'll break drivers that are not in mainstream linux routinely because you don't really care. Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] remove DRM IRQ installation funcs
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote: As for the new development model... Things are actually worse than I thought. There are some fairly large differences between linux-core and upstream, some of which have been in linux-core for a long time. It's one thing to have an out-of-tree development process but another entirely to let stuff rot for months years there. It just adds to the already huge set of driver combinations we have to worry about and support... How is doing merges preventing us from working on a single tree ? It's two completely separate problems. There are several problems, see the earlier thread Adapt on_each_cpu where we talked about the current dev process problems. I am outlining the fact that you confuse a problem and its solution. Problem: merging stuff upstream takes time to Dave Your solution: have lots of in-development trees and everyone upstreams its stuff which breaks other drivers and platforms A possible solution: everyone upstreams its stuff from a common tree which keeps other drivers and platforms working Maybe there are other solutions, I don't know. In any case, I would like to see a new model being agreed upon by the developers. I have not seen such an agreement yet. Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM development process
On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote: I am outlining the fact that you confuse a problem and its solution. Problem: merging stuff upstream takes time to Dave Your solution: have lots of in-development trees and everyone upstreams its stuff which breaks other drivers and platforms A possible solution: everyone upstreams its stuff from a common tree which keeps other drivers and platforms working Figured I should reply to this too (still trying to cool off after our heated discussion on IRC). I'm definitely *not* proposing a bunch of in-development trees to break other drivers and platforms. I don't want to break other drivers and platforms. Let me state again my issues: 1) drm master is way out of date wrt upstream Linux (and yes this is my fault too). This sucks and I'm trying to fix it by sending Dave easily digestible and tested patches against the tree he'll send to Linus for 2.6.28. It seems to me that this is putting more work on Dave, because in the end he'll be the one merging back from the kernel to linux-core. But then the stuff he merges might have become stale so it's more work. Not to mention the linux-core directory also has things to upstream, so we're talking 2-way merges. 2) our current development process makes it fairly easy to get into situation (1). It's far too easy to push something into drm master and assume Dave will take care of it. It's also easy to push something in that the BSD guys miss, causing them to do extra work next time they merge (hmm wtf is this new code supposed to do?) Sure, to which a possible answer is upstream your own stuff. Again I suppose there could be more answers, but it's a simple first step. Maybe once the un-upstreamed stuff is cleared, we can move on more easily with other things. 3) dealing with ongoing Linux changes in the drm tree is harder than it has to be (we just continually add more compat code all the time, and things often break with new kernel updates) OTOH with the current scheme developers/testers can keep their old kernel. All the nouveau users do that for example, the backwards compatibility doesn't seem impossible to do and that certainly didn't preven the DRM from working for years. So really I'm just looking for solutions to (2) and (3). For me, that means developing testing against a Linux tree first, since that's what goes upstream and that's what I have to support. It doesn't mean I can't push the resulting patches into drm master or work with people to make sure things get ported to BSD, etc. I don't think there are any silver bullets here. No matter what we do I think it's a lot of work. On a more personal note, statements like the below really suck: ... marcheu jbarnes: it was working fine before you were here, dude ... Oh, I realize this statement could be misinterpreted as you're responsible for breaking the drm or some such. I meant our drm development model was working fine for a long time before you were here, so why change it. We used to support Linux/BSD and under development/un-upstreamed drivers in a single tree. We might lose this and I think that's a mistake. If you ask me we just need to change the who's upstreaming what bit for now. I don't think there is an inherent problem to sharing the DRM tree. MrCooper yeah, it was fine before people stopped caring for anything but their little niche ... The core of the issue is there though. Do we still want to share stuff, or do we want to work in our own separate trees. And if we have separate trees, what's the policy for the shared infrastructure: how are the interfaces designed, how many drivers must implement it before upstreaming it... Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote: I might be totaly wrong so feel free to ignore these. I got the feeling that the user test base on linux kernel is far bigger than ours. Also i think that our test user base are people wanting lastest things with old kernel, while i understand that (building kernel is not fun on my ram slim computer) i think this end up being a burden to us. So in the end i think we should be better off with linux development tree where dev know the deadline to get feature in. I got the feeling that this way we could drive development on features basis like getting vblank rework done for a given kernel release and so get dev to focus more on some features and get them done in a timely fashion. This way we could avoid to get some new feature to rot a bit in the drm tree because. Also i think the linux-next or other linux bleeding edge tree would give us lot more tester with a lot more experience on good bug report that our current test base (i am not saying that we have bad tester, we have some very good one too which we should give credits, just that we might be able to get more of them). Judging by the current trend (where we see lots of people reporting the recent shmem_file_setup breakage because they tried to load git drm on a non-tip kernel), we have a lot of testers that don't run latest kernels but still get drm git. So the argument of more testers may not be true. Now that I think about it, is there a way with git to : 1. have a single main drm branch (that is, keep drm git the way it is right now) 2. inside this branch, maintain a number of changesets (each of those changesets would be an in-development feature). It seems to me we'd get the best of both worlds that way; the changesets would let us submit features upstream easily, and no push/pull would be needed to update all the repos. Seeing how most drm developments do not overlap, requiring explicit pull/pushes with merges sounds more complex than it needs to be. Now I'm not sure if it's possible, but at least I don't see a technical reason this wouldn't. Stephane - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti [EMAIL PROTECTED] wrote: Hi Jakob, Jakob Bornecrantz escreveu: The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client responsibility. The coordinates that we feed the kernel will be relative to the crtc and in pixels of scanout buffer. We do not have a 2D/3D acceleration API in the kernel. Nor should we have a mouse position calculation API in the kernel either. Cursor is in the kernel because in the new world of kernel modesetting you don't map registers to userspace you talk to them via the kernel. I am a bit divided if any of the above have a place in the DRM userspace library. Yeah, but the current design in the kms (i.e. DRM touching the registers) is not good as well. The pointer is jumping a lot -- much more than the old design -- because with a single device movement it emits a hundred of events and a lot of context switch is done. Not cool. Care to elaborate ? What you describe here sounds like an implementation-specific issue, more than an issue with KMS. Stephane - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon r6xx DRM...
If the new driver won't be an incremental change to the existing radeon drivers, I'd recommend basing it on Gallium. Hi Brian, It seems like people are mostly concerned about gallium stability right now. How stable wioll the interfaces be in the future ? Maybe if you could tell us, that'd help others jump in. Stephane - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM vs GEM discussion questions
On 5/16/08, Pekka Paalanen [EMAIL PROTECTED] wrote: On Fri, 16 May 2008 10:05:18 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: My current understanding is that on newer GPU each client got its own memory address space on the GPU. I can manage this space transparently based on hint from userspace, ie i can place page either in ram or vram and i can do migration when necessary. As a result i think i have no obligation that page in VRAM to be adjacent each to the other. Of course mapping such thing in userspace vma become cumberstone. This sounds like a feature that could be used to avoid applying any relocations into commands streams, and completely get rid of kernel validation of a command stream beforehand, allowing direct unobstructed command submission from user space to the card. It would just be like applying relocations in hardware, using page tables instead of rewriting addresses in certain spots in a command stream. Or have I misunderstood something? (Oh, in a later email Glisse writes the same idea.) This sounds interesting, since it would promote command submission that does not go through the kernel at all, which is what Nouveau is already interested in. Somehow I have a recollection that TTM would force the command stream through the kernel, but then again, I'm very new to all this. Yes, that was really my point. If the memory manager we use (whatever it is) does not allow this kind of behaviour, that'll force all cards to use a kernel-validated command submission model, which might not be too fast, and more difficult to implement on such hardware. I'm not in favor of having multiple memory managers, but if the chosen one is both slower and more complex to support in the future, that'll be a loss for everyone. Unless we want to have another memory manager implementation in 2 years from now... Stephane - 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
Re: TTM vs GEM discussion questions
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote: Yes, that was really my point. If the memory manager we use (whatever it is) does not allow this kind of behaviour, that'll force all cards to use a kernel-validated command submission model, which might not be too fast, and more difficult to implement on such hardware. I'm not in favor of having multiple memory managers, but if the chosen one is both slower and more complex to support in the future, that'll be a loss for everyone. Unless we want to have another memory manager implementation in 2 years from now... Stephane First, TTM does not enforce kernel command submission, but it forces you to tell the kernel about command completion status in order for the kernel to be able to move and delete buffers. Yes, emitting the moves from the kernel is not a necessity. If your card can do memory protection, you can setup the protection bits in the kernel and ask user space to do the moves. Doing so means in-order execution in the current context, which means that in the normal case rendering does not need to synchronize with fences at all. I'm not sure how you could avoid that with ANY kernel based memory manager, but I would be interested to know how you expect to solve that problem. See above, if the kernel controls the memory protection bits, it can pretty much enforce things on use space anyway. As for speed, the TTM-based i915tex driver is still substantially more CPU-efficient (which translates to faster for CPU-bound apps), than _any_ of the intel-modified drivers. Well, this is on intel hardware. If you had the ability to avoid most of the kernel trips and relocation thanks to your hw, you would be even less CPU-bound. Among other things, the texsubimage throughput is about 5x that of the Intel drivers, GEM included. I'm not arguing against TTM or against GEM right now... What we're discussing is something that wouldn't work in either case I think. Stephane - 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
Re: TTM merging?
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote: What you fail to notice here is that I think most people intend to have only one memory manager in the kernel. How on earth can you draw that conclusion from the above statement? Well, Dave has been saying this to me all along... otherwise I'd probably have my own memory manager too. I also think most people agree that a single memory manager would make things simpler for everyone (especially since there is a need for some glue with things like EXA). So making the wrong decisions here will pretty much enforce those decisions on all drivers. And therefore, we will not be able to do what you want to What GEM protagonists have been arguing and propagating for is not a single memory manager, but a single small common simple memory management interface to that would allow any driver writer to do pretty much what they want with their driver. As you might have noticed we're not really arguing against that. Yeah, again, I'm not taking sides, I'm just concerned that we'll have to revisit the memory manager issue in 2 years when all cards implement full memory protection and paging (and that'll be the case, since the windows driver model pretty much requires that). But maybe it's the right thing to do to move forward now. Stephane - 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
Re: TTM merging?
On 5/14/08, Dave Airlie [EMAIL PROTECTED] wrote: I was hoping that by now, one of the radeon or nouveau drivers would have adopted TTM, or at least demoed something working using it, this hasn't happened which worries me, perhaps glisse or darktama could fill in on what limited them from doing it. The fencing internals are very very scary and seem to be a major stumbling block. Aside from the fencing code, I have some othern more general, concerns with respect to using TTM on recent hardware. Although I've raised them before, it was on IRC, not really on the list. The main issue in my opinion, is that TTM enforces most things to be done form the kernel, and how those things should be done: command checking with relocations, fence emission, memory moves... Depending on the hardware functionality available, this might be useless or even counter-productive. Also, I'm concerned about handling chips that can do page faults in video memory. It is interesting to be able to use this feature (which was asked for by the windows guys). For example we could have the ability to have huge textures paged in progressively at the memory manager level. So to me the current TTM design lacks enough flexibility for recent chip features. I'm not saying all of this has to be implemented now, but it should not be prevented by the design. After all, if the memory manager is here to stay, I'd say it needs to be future-proof. Stephane - 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
Re: Gallium: Fix for tgsi_emit_sse2()
So, we should really fix this. The two options are : - Keep a different calling convention under linux (cdecl by default, which requires saving esi by hand in the shader) and apply Victor's patch which saves restores this register - Use the same calling convention on all platforms, that is change include/pipe/p_compiler.h to define XSTDCALL to stdcall on linux, because for now it's empty, which is _not_ stdcall but cdecl. In any case, this is a serious issue as under linux esi gets corrupted on return from the SSE call. Which, of course, causes crashes. Stephane - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI Summer of Code ?
Ok, the DRI application for summer of code just went in (at the very last minute). Thanks to those who joined in and filled our project page, and hopefully talk to you when discussing projects :) Stephane - 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
Re: DRI Summer of Code ?
Ok, anyone else interested (ATM it's Jerome - Idr - Alex - me) ? The deadline for project applications is wednesday so we'll have to write the proposal for DRI quick now. Hopefully it works out. Stephane - 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
Re: DRI Summer of Code ?
On 3/11/08, Ian Romanick [EMAIL PROTECTED] wrote: Link missing in previous post: http://dri.freedesktop.org/wiki/GSoC_2008 I added a couple of ideas to the page. Who's next ? :) Stephane - 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
DRI Summer of Code ?
Hi, I often hear DRI developers talking about how we lack contributors. Well, this is the occasion, I think we could get together and try to propose DRI as a separate organization for the google summer of code (it's also good to have DRI seen as a separate project from the outside, and not just another TLA, for the exact same reason). I also don't think there is enough room that DRI should/could be part of X.Org, seeing how X.Org got, uh, 2 slots last year. So ? If enough devs are interested, I could write a proposal. But we have to act pretty quick. Stephane - 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
Re: redesigning the DRM internal logic..
On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote: So I've been thinking about this stuff a lot lately wrt to getting the DRM into a state that enables fast-user-switching, GPGPU apps, different users on a per head one a single card.. http://dri.freedesktop.org/wiki/DRMRedesign has a nice picture and some notes.. either comment direct on the webpage, or reply here.. A lot of the code heading in this direction just got merged into modesetting-101, it should in theory all be backwards compat in the single render/master case... Hi, So basically, you'd expose multiple /dev entries for a single piece of hardware. As I said on irc, this would be like exposing /dev/sda1_ext2 and /dev/sda1_xfs and ... which obviously doesn't scale long-term. Lets forget about the concept of master for a moment. In a case where the concept of master does not exist, an application that can draw to screen (formerly master) would simply be one that has a scanout BO and is using it. So here is the point: with the current work on enforcing proper permissions on BOs (including scanout BOs), is a separate device really needed ? The reason for doing this device separation in the first place basically comes down to enforcing those permissions properly in a per-app fashion. The same effect could be achieved by enforcing the policy on BO creation instead of device opening. Stephane - 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
Re: redesigning the DRM internal logic..
On 2/13/08, Jesse Barnes [EMAIL PROTECTED] wrote: On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin wrote: On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote: So I've been thinking about this stuff a lot lately wrt to getting the DRM into a state that enables fast-user-switching, GPGPU apps, different users on a per head one a single card.. http://dri.freedesktop.org/wiki/DRMRedesign has a nice picture and some notes.. either comment direct on the webpage, or reply here.. A lot of the code heading in this direction just got merged into modesetting-101, it should in theory all be backwards compat in the single render/master case... Hi, So basically, you'd expose multiple /dev entries for a single piece of hardware. As I said on irc, this would be like exposing /dev/sda1_ext2 and /dev/sda1_xfs and ... which obviously doesn't scale long-term. Lets forget about the concept of master for a moment. In a case where the concept of master does not exist, an application that can draw to screen (formerly master) would simply be one that has a scanout BO and is using it. So here is the point: with the current work on enforcing proper permissions on BOs (including scanout BOs), is a separate device really needed ? The reason for doing this device separation in the first place basically comes down to enforcing those permissions properly in a per-app fashion. The same effect could be achieved by enforcing the policy on BO creation instead of device opening. IIRC, the reason we came up with this was to deal with CRTC-output mapping, not for BO permissions so much (doing proper perms there still requires a lot of work). You don't want any application to be able to change CRTC-output mappings, or bind BOs to CRTCs. Ideally you'd just have one app that could do that on a given system, and it would contain the distribution's policy regarding output cloning, hotplug actions, etc. I don't see how that interferes with the solution I propose ? I'm not discussing policy but where to store the policy. The existence of one client being able to scanout at a time is ovbious in any case. So the master/slave concept is really more analogous to pty master slave nodes than it is to your /dev/sda_ext3 example. You open the master node, ask for a specific mapping, and if you have permission, a slave node will be created that you can do what you like with... Yeah, probably my analogy is far from perfect. Since people seem to concentrate on the analogy instead of the point, let me state the point. My point is that exposing different uses for a device should not be exposed through separate /dev entries. GPGPU is obviously a very recent trend. Will we have to add new /dev entries for future trends as well, and how future proof is that ? Obviously other (binary) drivers do fine without thanks to more flexible interfaces. I still wonder what suddenly mandates the addition of a GPGPU-specific device node to DRM, can't we be flexible instead ? Stephane - 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
Re: redesigning the DRM internal logic..
On 2/14/08, Jesse Barnes [EMAIL PROTECTED] wrote: On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote: You don't want any application to be able to change CRTC-output mappings, or bind BOs to CRTCs. Ideally you'd just have one app that could do that on a given system, and it would contain the distribution's policy regarding output cloning, hotplug actions, etc. I don't see how that interferes with the solution I propose ? I'm not discussing policy but where to store the policy. The existence of one client being able to scanout at a time is ovbious in any case. I don't know if it interferes, but I also can't see how your proposal deals with this case. Can you provide more details? Just saying a BO has scanout permission isn't sufficient either, since CRTC-output mappings are important too and not covered by BO permissions. There is always the possibility of So the master/slave concept is really more analogous to pty master slave nodes than it is to your /dev/sda_ext3 example. You open the master node, ask for a specific mapping, and if you have permission, a slave node will be created that you can do what you like with... Yeah, probably my analogy is far from perfect. Since people seem to concentrate on the analogy instead of the point, let me state the point. My point is that exposing different uses for a device should not be exposed through separate /dev entries. GPGPU is obviously a very recent trend. Will we have to add new /dev entries for future trends as well, and how future proof is that ? Sure, I don't think anyone will disagree with that: we shouldn't be exposing /dev/feature_bong and /dev/feature_hits, however doing a logical split on device capability (as opposed to application) does make sense. For instance, sound devices expose mixer, midi, and raw digital audio nodes, since the functions are relatively independent with their own interfaces and possibly permissions. Similarly, output control, rendering to a screen and running programs are separate functions of a modern GPU (though you could argue that the last is a subset of rendering to a screen). Well, you're using the example of fully in-kernel drivers here. In that case, it does make sense because there is no user space layer to expose different APIs/functionality. However, the DRM is a little different. Its interface doesn't carry OpenGL or even 3D semantics on it, nor does it carry 2D/EXA nor GPGPU. However, all these can and are exposed by some user space library using the DRM. And we do not have a need for different interfaces at the kernel level, since our APIs are exposed at some higher level. Stephane - 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
Re: redesigning the DRM internal logic..
On 2/14/08, Stephane Marchesin [EMAIL PROTECTED] wrote: I don't know if it interferes, but I also can't see how your proposal deals with this case. Can you provide more details? Just saying a BO has scanout permission isn't sufficient either, since CRTC-output mappings are important too and not covered by BO permissions. There is always the possibility of Woops early-send clicking, sorry. There is always the possibility of attaching those permissions elsewhere. Technically I don't see what prevents you from attaching to the BO. Stephane - 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
Re: Clip Lists
On 28 Nov 2007 06:19:39 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote: Stephane Marchesin [EMAIL PROTECTED] writes: I fail to see how this works with a lockless design. How do you ensure the X server doesn't change cliprects between the time it has written those in the shared ring buffer and the time the DRI client picks them up and has the command fired and actually executed ? Do you lock out the server during that time ? The scheme I have been advocating is this: - A new extension is added to the X server, with a PixmapFromBufferObject request. - Clients render into a private back buffer object, for which they used the new extension to generate a pixmap. - When a client wishes to copy something to the frontbuffer (for whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses plain old XCopyArea() with the generated pixmap. The X server is then responsible for any clipping necessary. This scheme puts all clip list management in the X server. No cliprects in shared memory or in the kernel would be required. And no locking is required since the X server is already processing requests in sequence. Yes, that is the idea I want to do for nvidia hardware. Although I'm not sure if we can/want to implement it in term of X primitives or a new X extension. To synchronize with vblank, a new SYNC counter is introduced that records the number of vblanks since some time in the past. The clients can then issue SyncAwait requests before any copy they want synchronized with vblank. This allows the client to do useful processing while it waits, which I don't believe is the case now. Since we can put a wait until vblank on crtc #X command to a fifo on nvidia hardware, the vblank issue is non-existent for us. We get precise vblank without CPU intervention. Stephane - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On 11/28/07, Keith Packard [EMAIL PROTECTED] wrote: On Wed, 2007-11-28 at 00:52 +0100, Stephane Marchesin wrote: The third case obviously will never require any kind of state re-emitting. Unless you run out of hardware contexts. Well, in that case we (plan to) bang the state registers from the kernel directly and do a manual state swap. So we still don't need state re-emitting. Stephane - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Swapbuffers [was: Re: DRI2 and lock-less operation]
On 11/28/07, Keith Whitwell [EMAIL PROTECTED] wrote: In my ideal world, the entity which knows and cares about cliprects should be the one that does the swapbuffers, or at least is in control of the process. That entity is the X server. Instead of tying ourselves into knots trying to figure out how to get some other entity a sufficiently up-to-date set of cliprects to make this work (which is what was wrong with DRI 1.0), maybe we should try and figure out how to get the X server to efficiently orchestrate swapbuffers. In particular it seems like we have: 1) The X server knows about cliprects. 2) The kernel knows about IRQ reception. 3) The kernel knows how to submit rendering commands to hardware. 4) Userspace is where we want to craft rendering commands. Given the above, what do we think about swapbuffers: a) Swapbuffers is a rendering command b) which depends on cliprect information c) that needs to be fired as soon as possible after an IRQ receipt. So: swapbuffers should be crafted from userspace (a, 4) ... by the X server (b, 1) ... and should be actually fired by the kernel (c, 2, 3) Well, on nvidia hw, you don't even need to fire from the kernel (thanks to a special fifo command that waits for vsync). So I'd love it if going through the kernel for swapbuffers was abstracted by the interface. I propose something like: 0) 3D client submits rendering to the kernel and receives back a fence. 1) 3D client wants to do swapbuffers. It sends a message to the X server asking it please do me a swapbuffers after this fence has completed. 2) X server crafts (somehow) commands implementing swapbuffers for this drawable under the current set of cliprects and passes it to the kernel along with the fence. 3) The kernel keeps that batchbuffer to the side until a) the commands associated with the fence have been submitted to hardware. b) the next vblank IRQ arrives. when both of these are true, the kernel simply submits the prepared swapbuffer commands through the lowest latency path to hardware. But what happens if the cliprects change? The 100% perfect solution looks like: The X server knows all about cliprect changes, and can use fences or other mechanisms to keep track of which swapbuffers are outstanding. At the time of a cliprect change, it must create new swapbuffer commandsets for all pending swapbuffers and re-submit those to the kernel. These new sets of commands must be tied to the progress of the X server's own rendering command stream so that the kernel fires the appropriate one to land the swapbuffers to the correct destination as the X server's own rendering flies by. Yes that was the basis for my thinking as well. By inserting the swapbuffers into the normal flow of X commands, we remove the need for syncing with the X server at swapbuffer time. In the simplest case, where the kernel puts commands onto the one true ring as it receives them, the kernel can simply discard the old swapbuffer command. Indeed this is true also if the kernel has a ring-per-context and uses one of those rings to serialize the X server rendering and swapbuffers commands. Come on, admit that's a hack to get 100'000 fps in glxgears :) Note that condition 3a) above is always true in the current i915.o one-true-ring/single-fifo approach to hardware serialization. Yes, I think those details of how to wait should be left driver-dependent and abstracted in user space. So that we have the choice of calling the kernel, doing it from user space only, relying on a single fifo or whatever. I think the above can work and seems more straight-forward than many of the proposed alternatives. This is what I want to do too. Especially since in the nvidia case we don't have the issue of routing vblank interrupts to user space for that. So, the only issue I'm worried about is the latency induced by this approach. When the DRM does the swaps you can ensure it'll get executed pretty fast. If X has been stuffing piles of commands into its command buffer, it might not be so fast. What this means is that 3D might be slowed down by 2D rendering (think especially of the case of EXA fallbacks which will sync your fifo). In that case, ensuring a no-fallback EXA would become relevant in achieving smooth 3D performance. But at least it solves the issue of sluggish OpenGL window moves and resizes (/me looks at the nvidia binary driver behaviour). Stephane - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: Clip Lists
On 11/28/07, Keith Whitwell [EMAIL PROTECTED] wrote: Stephane Marchesin wrote: On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Stephane Marchesin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: I fail to see how this works with a lockless design. How do you ensure the X server doesn't change cliprects between the time it has written those in the shared ring buffer and the time the DRI client picks them up and has the command fired and actually executed ? Do you lock out the server during that time ? The scheme I have been advocating is this: - A new extension is added to the X server, with a PixmapFromBufferObject request. - Clients render into a private back buffer object, for which they used the new extension to generate a pixmap. - When a client wishes to copy something to the frontbuffer (for whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses plain old XCopyArea() with the generated pixmap. The X server is then responsible for any clipping necessary. This scheme puts all clip list management in the X server. No cliprects in shared memory or in the kernel would be required. And no locking is required since the X server is already processing requests in sequence. Yes, that is the idea I want to do for nvidia hardware. Although I'm not sure if we can/want to implement it in term of X primitives or a new X extension. To synchronize with vblank, a new SYNC counter is introduced that records the number of vblanks since some time in the past. The clients can then issue SyncAwait requests before any copy they want synchronized with vblank. This allows the client to do useful processing while it waits, which I don't believe is the case now. Since we can put a wait until vblank on crtc #X command to a fifo on nvidia hardware, the vblank issue is non-existent for us. We get precise vblank without CPU intervention. You still have some issues... The choice is: do you put the wait-until-vblank command in the same fifo as the X server rendering or not? If yes -- you end up with nasty latency for X as its rendering is blocked by swapbuffers. Yes, I want to go for that simpler approach first and see if the blocking gets bad (I can't really say until I've tried). Stephane - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On 11/27/07, Thomas Hellström [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: On Nov 22, 2007 4:03 AM, Thomas Hellström [EMAIL PROTECTED] wrote: ... There are probably various ways to do this, which is another argument for keeping super-ioctls device-specific. For i915-type hardware, Dave's approach above is probably the most attracting one. For Poulsbo, all state is always implicitly included, usually as a reference to a buffer object, so we don't really bother about contexts here. For hardware like the Unichrome, the state is stored in a limited set of registers. Here the drm can keep a copy of those registers for each context and do a smart update on a context switch. However, there are cases where it is very difficult to use cliprects from the drm, though I wouldn't say impossible. The idea is to keep the cliprects in the kernel and only render double buffered. The only code that needs to worry about cliprects is swap buffer, either immediate or synced to vblank. What are the cliprect problems you mention? Kristian Hi, Kristian. Sorry for the late response. What I'm thinking about is the case where the swapbuffers needs to be done by the 3D engine, and with increasingly complex hardware this will at the very least mean some sort of pixel-shader code in the kernel, or perhaps loaded by the kernel firmware interface as a firmware snippet. If we take Poulsbo as an example, the 2D engine is present and open, and swapbuffers can be done using it, but since the 2D- and 3D engines operate separately they are synced in software by the TTM memory manager fence class arbitration code, and we lose performance since we cannot pipeline 3D tasks as we'd want to. If the 3D engine were open, we'd still need a vast amount of code in the kernel to be able to just to a 3D blit. Then why don't you do it in user space ? You could very well do swapbuffers in the DDX (and cliprects then become a non-issue). This is even more complicated by the fact that we may not be able to implement 3D blits in the kernel for IP protection reasons. Note that I'm just stating the problem here. I'm not arguing that this should influence the DRI2 design. Yes, I don't think we should base the open source DRI design upon specs that have to be kept hidden. Especially if that hardware is not relevant in any way technically. Stephane - 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: DRI2 and lock-less operation
On 11/27/07, Keith Packard [EMAIL PROTECTED] wrote: On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: -full state I assume you'll deal with hardware which supports multiple contexts and avoid the need to include full state with each buffer? That's what we do already for nouveau, and there are no issues to implementing it. Really that's driver-dependent, like the radeon atom emission mechanism is. Stephane - 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: DRI2 and lock-less operation
On 11/22/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: Hi all, I've been working on the DRI2 implementation recently and I'm starting to get a little confused, so I figured I'd throw a couple of questions out to the list. First of, I wrote up this summary shortly after XD http://wiki.x.org/wiki/DRI2 which upon re-reading is still pretty much up to date with what I'm trying to do. The buzzword summary from the page has * Lockless * Always private back buffers * No clip rects in DRI driver * No DDX driver part * Minimal X server part * Swap buffer and clip rects in kernel * No SAREA I've implemented the DRI2 xserver module (http://cgit.freedesktop.org/~krh/xserver/log/?h=dri2) and the new drm ioctls that is uses (http://cgit.freedesktop.org/~krh/drm/log/?h=dri2). I did the DDX part for the intel driver and DRI2 initialization consists of doing drmOpen (this is now up to the DDX driver), initialize the memory manager and use it to allocate stuff and then call DRI2ScreenInit(), passing in pScreen and the file descriptor. Basically, all of i830_dri.c isn't used in this mode. It's all delightfully simple, but I'm starting to reconsider whether the lockless bullet point is realistic. Note, the drawable lock is gone, we always render to private back buffers and do swap buffers in the kernel, so I'm only concerned with the DRI lock here. The idea is that since we have the memory manager and the super-ioctl and the X server now can push cliprects into the kernel in one atomic operation, we would be able to get rid of the DRI lock. My overall question, here is, is that feasible? How do you plan to ensure that X didn't change the cliprects after you emitted them to the DRM ? I'm trying to figure out how context switches acutally work... the DRI lock is overloaded as context switcher, and there is code in the kernel to call out to a chipset specific context switch routine when the DRI lock is taken... but only ffb uses it... So I'm guessing the way context switches work today is that the DRI driver grabs the lock and after potentially updating the cliprects through X protocol, it emits all the state it depends on to the cards. Is the state emission done by just writing out a bunch of registers? Is this how the X server works too, except XAA/EXA acceleration doesn't depend on a lot of state and thus the DDX driver can emit everything for each operation? How would this work if we didn't have a lock? You can't emit the state and then start rendering without a lock to keep the state in place... If the kernel doesn't restore any state, whats the point of the drm_context_t we pass to the kernel in drmLock? Should the kernel know how to restore state (this ties in to the email from jglisse on state tracking in drm and all the gallium jazz, I guess)? How do we identify state to the kernel, and how do we pass it in in the super-ioctl? Can we add a list of registers to be written and the values? I talked to Dave about it and we agreed that adding a drm_context_t to the super-ioctl would work, but now I'm thinking if the kernel doesn't track any state it wont really work. Maybe I seem to recall Eric Anholt did optimize the emission of radeon state atoms a long time ago, and he got some speed improvements. You'd have to ask him how much though. This could give us a rough idea of the performance impact of emitting full state vs needed state, although this doesn't measure the gain of removing lock contention. I might be totally wrong on this, this dates back to a couple of years ago. cross-client state sharing isn't useful for performance as Keith and Roland argues, but if the kernel doesn't restore state when it sees a super-ioctl coming from a different context, who does? Yes it probably has to go to the kernel anyway. Stephane - 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: DRI2 and lock-less operation
On 11/27/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Nov 27, 2007 11:48 AM, Stephane Marchesin [EMAIL PROTECTED] wrote: On 11/22/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: ... It's all delightfully simple, but I'm starting to reconsider whether the lockless bullet point is realistic. Note, the drawable lock is gone, we always render to private back buffers and do swap buffers in the kernel, so I'm only concerned with the DRI lock here. The idea is that since we have the memory manager and the super-ioctl and the X server now can push cliprects into the kernel in one atomic operation, we would be able to get rid of the DRI lock. My overall question, here is, is that feasible? How do you plan to ensure that X didn't change the cliprects after you emitted them to the DRM ? The idea was that the buffer swap happens in the kernel, triggered by an ioctl. The kernel generates the command stream to execute the swap against the current set of cliprects. The back buffers are always private so the cliprects only come into play when copying from the back buffer to the front buffer. Single buffered visuals are secretly double buffered and implemented the same way. What if cliprects change between the time you emit them to the fifo and the time the blit gets executed by the card ? Do you sync to the card in-drm, effectively killing performance ? I'm trying to figure now whether it makes more sense to keep cliprects and swapbuffer out of the kernel, which wouldn't change the above much, except the swapbuffer case. I described the idea for swapbuffer in this case in my reply to Thomas: the X server publishes cliprects to the clients through a shared ring buffer, and clients parse the clip rect changes out of this buffer as they need it. When posting a swap buffer request, the buffer head should be included in the super-ioctl so that the kernel can reject stale requests. When that happens, the client must parse the new cliprect info and resubmit an updated swap buffer request. I fail to see how this works with a lockless design. How do you ensure the X server doesn't change cliprects between the time it has written those in the shared ring buffer and the time the DRI client picks them up and has the command fired and actually executed ? Do you lock out the server during that time ? Stephane - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On 11/27/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: Yeah - I'm trying to limit the scope of DRI2 so that we can have redirected direct rendering and GLX1.4 in the tree sooner rather than later (before the end of the year). Maybe the best way to do that is to keep the lock around for now and punt on the lock-less super-ioctl if that really blocks on hardware context support. How far back is hardware contexts supported? Hmm you can't be binary like that. I think there are 3 classes of devices around : - no context support at all : old radeon, old intel - multiple fifos, no hw context switching : newer radeon, newer intel - multiple fifos, hw context switching : all nvidia The third case obviously will never require any kind of state re-emitting. Stephane - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [2.6 patch] make drm_sg_alloc() static
On 10/24/07, Adrian Bunk [EMAIL PROTECTED] wrote: drm_sg_alloc() can now become static. FWIW there is at least one consumer of it in drm git. Stephane - 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: Current state
Dave Brown wrote: Hi there, I've recently become interested in the Nouveau project. Specifically I'm considering looking at porting it to a relatively unknown operating system called RISC OS that is based on the ARM processor. The platform I would be targeting currently has uses either a GeForce 2 MX 400 (NV14?) or GeForce 5200 (NV34) . I was wondering what the state of support for these chips currently is. Unfortunately the processor in use (XScale IOP80321) doesn't have any form of floating point hardware so any support for HW TL/Vertex shaders would be seriously beneficial. Hello, Don't expect much for now, we're still working on DRI support. For now we can only run a couple of applications (glxgears and some other simple tests) and only on some NV40 cards. NV11/NV34 support is still a work in progress (but might work any day now :). The current code uses software TCL, but with a bit of work we could add hardware TCL (we have the required information for that). Feel free to ask if you have any other questions ! Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [noveau] Nv03-06 driver source code
Svante Signell wrote: Dear Noveau developers, Some years ago, around 2000-2002 there was a guy in New Zealand, David, working on Nvidia drivers, see the message at the Utah-GLX mailing list archive from April 2002: http://sourceforge.net/mailarchive/forum.php?thread_id=612267forum_id=3646 hi I have started a project to build a NVRM witch will hopefully will give as the frist open source high performance dma nvidia driver first i have to build the NVRM this handles a lot of work to make the chip run and grates an unified interface to the hardware so you can have 2 or move clients torking to the hardware at the same time eg. a dvd player a X draw text and a opengl game . it also handles deferencs between the chips NV04 , NV05 , NV10 , NV20 and so on once i have done anuf of the NVRM working to support X and glx i will start on the X and glx clients my site for this project is http://homepages.ihug.co.nz/~lexos i will update as i go now its just the hard work :) Unfortunately the web page is no longer available and the person does not seem to work on nvidia drivers. Anyway, by the time I downloaded the source code and since there now exist a project for Nvidia 3d drivers, maybe parts of the source code can be of use for the Noveau developers. According to the code and some result files DMA and context switching seems to be functional. Also, some header files can be useful. Unfortunately the code is uncommented has no licence information (except for one nv03 header file), no README etc. Maybe the mailing list archives of utah-glx can be of use to find out more about this person if needed. Nevertheless, I can send the zip file with the sources to any of you who are interested. The file size is around 160kB, so it would probably not be accepted as an attachment to this mail. Hello, Yes, I think we have it already (nvsrc.zip right ?). Thanks anyway ! Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mesa: Branch 'master'
Keith Whitwell wrote: configs/linux-dri-debug | 16 1 files changed, 16 insertions(+) New commits: diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from 747c9129c0b592941b14c290ff3d8ab22ad66acb) Author: Keith Whitwell [EMAIL PROTECTED] Date: Wed Jan 17 08:44:13 2007 + New debug config for linux-dri Also, isn't it time that we use -O2 by default for linux-dri ? It brings quite a bit of performance increase. Failing that, can we add -O2 somewhere in the nouveau makefile (so that only our code gets built with it) ? Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mesa: Branch 'master'
Keith Whitwell wrote: Stephane Marchesin wrote: Keith Whitwell wrote: configs/linux-dri-debug | 16 1 files changed, 16 insertions(+) New commits: diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from 747c9129c0b592941b14c290ff3d8ab22ad66acb) Author: Keith Whitwell [EMAIL PROTECTED] Date: Wed Jan 17 08:44:13 2007 + New debug config for linux-dri Also, isn't it time that we use -O2 by default for linux-dri ? It brings quite a bit of performance increase. Failing that, can we add -O2 somewhere in the nouveau makefile (so that only our code gets built with it) ? I don't have a problem with doing this in configs/linux-dri, providing the '-fno-strict-aliasing' flag is set in there somewhere too. Ok, I'll wait for a couple of days, and if no one raises a reason why we shouldn't do that, I'll change it. Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] a million little pieces affecting nvidia drivers
Alexy Khrabrov wrote: Philipp, Mark -- Thanks for the concise and extremely useful explanation! This is worthy of being on the front page of a wiki. Also, there is that : http://people.freedesktop.org/~ajax/dri-explanation.txt Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] Formal offer from the nouveau driver pledge drive
David Nielsen wrote: Dear Nouveau developers It is my pride and honor on behalf of myself and 1247 other pledgers (as of current writing) to formally offer up the sum of ~10.000$ in the form of 1248 pledges of at least 10$ each. It is entirely up to you, the nouveau developers, if you want to accept this donation and if so what you elect to do with the money. We offer it up without strings attached though naturally with the hope that it goes towards easing your lives a bit and help the world reap the benefits of your hard labor as soon as possible. There are boring technical details to take care of in regards to the actual donations to take place and should you elect to take this offer I will do my best to be helpful in working them out. I know this pledge drive has caused both trouble and confusion for you all, for that I personally apologize as well. Thank you for your hard work. Kind regards, David Nielsen Hello, I just wanted to thank you and all the pledgers on behalf of other nouveau developers and myself. We're not quite sure how we are going to spend all that money yet (maybe on hardware, but even then that's a lot of hardware), but we'll setup a page with our plans when we have made our minds. Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] drm/nouveau locks on suse 10.2 with nvidia GeForce 2 Go
Alexy Khrabrov wrote: [forwarding to the list as well] Here it is, below. I manually modprobe agpgart to make drm.ko happy. Do I have to recompile something else -- it complains about drm? The screen goes blank and doesn't come back, but ctrl-alt-del still reboots. Cheers, Alexy Here is my take : X startups, and crahes, leaving a blank console. Could you start it as follows : startx 2 log.txt And send the result ? Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] drm/nouveau locks on suse 10.2 with nvidia GeForce 2 Go
Alexy Khrabrov wrote: Greetings -- compiled drm and nouveau yesterday from git and tried to run X -- hangs at the loading stage. Xorg.0.log attached. I've followed the following checks: -- kernel compiled with DRM disabled -- binary nvidia module not loaded The drm installed libdrm.so in /usr/local/lib, I copied them to /usr/lib; similarly, copied nouveau_drv.so from /usr/local/lib/xorg to /usr/lib/xorg. Are there other pieces I'm missing? Do you have a kernel log as well ? Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Interest for PCI / PCIe tracing for Nouveau -project?
Phillip Ezolt wrote: Stephane, What tools do you use for tracing? I know that you have the renouveau tool and libsegfault. I'm hacking on the ATI stuff, and it would be handy to have code which can just out what MMIO writes the kernel driver is doing. Do you guys have anything to do that? Yes, and it was just importer into git : git://people.freedesktop.org/~jrmuizel/mmio-trace Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Interest for PCI / PCIe tracing for Nouveau -project?
Simen Thoresen wrote: Hi Nouveau- (and other cheap PCI and PCIe -graphics users) I have several PCI and PCIe tracers available through my employer, and will be able to purchase low-end versions of modern video-cards (preferably PCI versions, but possibly PCIe versions as well) for machines that will run both Windows and Linux. I'll probably have time to perform simple tests and grabs with these cards if I have something to look for. Please note that I am not a hardware (or software) developer, so I'll be learning to use the grabbers as we go along :-) Would any of you benefit from this? Hello, Thanks for your offer. That would surely be interesting, although it might generate huge logs. We have a number of tools that can achieve similar tasks (and which we can run at home, so as not to annoy someone else) , se we can probably get around it for now. However, PCI tracers are very useful when tracing weird bugs, so I might contact you at a later point. And if other nouveau devs are interested, I'll let them jump in :) Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Tried it on my G5 Quad
Michael Buesch wrote: On Friday 15 December 2006 16:53, Michel Dänzer wrote: On Fri, 2006-12-15 at 15:17 +0100, Michael Buesch wrote: I just tried to load the nouveau driver on my Apple G5 Quad machine. The kernel module loaded fine, but an attempt to start the x-server resulted in a frozen userinterface. Actually, the logs look like the X server aborts, e.g. due to an unresolved symbol. Try redirecting its stdout and stderr and looking at that. No, it didn't abort. It froze.Why do you think it aborted? Truncated X-log?The Xserver began to start, the console went black and the cursorinto the upper left corner and stopped blinking.I had to access the machine through ssh to get the logs.I think it might be a conflict between the loaded nvidia framebufferdriver and nouveau. Did you try that? nvidia-fb and nouveau at thesame time? I will try without nvidia framebuffer driver. -- Greetings Michael. nvidiafb and nouveau at the same time is an unsupported combination. Use offb or vesafb. Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Porting DRI to New Platform
[EMAIL PROTECTED] wrote: Hello, I'm Dee Sharpe and I have been working on the Syllable port of Mesa3d. Now it is time to move on to hardware acceleration. What would it take to port the DRI to another windowing system? The glue code that I have to write will be in C++. If anyone has pointers or guidelines on what I need to get the DRI running, I would be very thankful. I don't think there's any guide to that. For a typical port to unix/Xorg, you'd only need to port the DRM (which is the kernel component) and that's about it. However Syllable doesn't use Xorg so stuff that's usually setup in the DDX will have to be done by your current 2D driver. Also, your 2D driver will have to cooperate with the 3D driver nicely, which is not always given. You may want to talk with the BeOS/Haiku guys, I think they considered doing the same at some point, not sure if they tried however. Stephane - 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Where to start?
Anna Lissa Cruz wrote: Hi all, I just signed onto the list. I'm working with Rudi Cilibrasi and wondering where's the best place to start contributing. We're both C programmers, with some OpenGL experience, and have NV35 and NV36 cards to play with. We have checked out the feature matrix, and see there are a couple of TODOs and a few WIPs. Should we just pick a TODO? Or perhaps there's a WIP we can cut our teeth on? Hello First of all, I would advise going through existing development, to get a feel of what's done and what's left. There's quite a bit of reading about past development on the wiki. Next, we have a TODO list here : http://nouveau.freedesktop.org/wiki/ToDo Feel free to pick an item you want. If you have issues figuring how to get there, or wonder how hard implementing a speficic feature is, just drop by on irc.freenode.net channel #nouveau and ask what's the way to implementing feature X ? Stephane - 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: question on nv35 versus nv30 protocol
Rudi Cilibrasi wrote: Hi everybody, I have just started trying to contribute to this project and got as far as identifying chip family for the two cards I have access to here: NV35 and NV36. I added a column for NV35 assuming that the protocol would be different than NV30 in the TODO matrix, but now am wondering if this is correct. Does anybody know yet or will I just have to find out myself through experimentation? Hello, Yes, NV35 is mostly the same as NV30 (at least we have still to find any difference between the NV3X models with respect to 3D operation). Stephane - 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Thomas Hellström wrote: Benjamin Herrenschmidt wrote: On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: But this should be the same problem encountered by the agpgart driver? x86 and x86-64 calls change_page_attr() to take care of this. On powerpc it is simply a noop. (asm/agp.h) Possibly. We sort-of ignore the issue for now on PowerPC and happen to be lucky most of the time because 32 bits PowerPC aren't that agressive at prefetching... I haven't looked at change_page_attr() implementation on x86 but I know they also map the linear mapping with large pages. I don't know what happens if you start trying to change a single page attribute. x86 can breakup that large page into 4k pages, so maybe that's what happens. Yes, I think that's what happens. I know some Athlon chips had a big issue with this some time ago. I notice there are special functions in agp.h to alloc / free GATT pages, so the general idea might be to have a pool of uncached pages in the future for powerpc? Even better would perhaps be to have pages that aren't mapped for the kernel. (like highmem pages on x86). As a side note, it's not always possible to map the whole video memory. For example on ATI chips you can't map VRAM above 128MB, on Nvidia you can't above 256MB. Still, that memory has to be managed somehow. In that case, such memory areas will be hidden from the application anyway. Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM memory manager on cards with hardware contexts
Hello, Before explaining the issue, let me first introduce the context a bit. We are working on hardware that supports multiple contexts. By allocating one context to each application, we can achieve full graphics command submission from user space (each context is actually simply a command fifo and its control registers which are both mapped into the application space). Obviously, we are interested in making use of the new DRM memory manager on that hardware. Now if I understand how it works correctly, this new memory manager allocates opaque handles which are not to be used as offset in memory, because they are not. Therefore, a translation from the handle into a proper memory adress has to be done before the commands are sent to the hardware. This is easy to add when the DRM validates all the commands. However in our model the drm does can not do so, since it does not validates each and every command that is sent. So we need to be able to translate the handles into real offsets from user space, and know for sure that these offsets will remain valid for as long as the hardware will need them. And that's where we're out of ideas. Do you guys think it's possible to work around that ? Stephane PS : before everyone jumps in and says that this model is insecure, let me add that the hardware can enforce memory access - 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm addmap broken on 32bit archs
Stephane Marchesin wrote: Hello, The drm addmap code got broken with the recent switch to the hash table implementation. Specifically, when two maps have the same adress on 32 bits, they end up with the same key and nothing is done to resolve the collision, which results in a failind addmap. This is annoying. nm, Dave and Michel both told me that this was fixed already. Stephane - 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: disconnected texture tiles
James C Georgas wrote: There are black grid lines between some terrain tiles in various games I have. It seems to happen in both software and direct rendering. I'm using this morning's cvs HEAD for mesa and dri. System is dual Opteron. Video card is FireGL X1-128 OS is Gentoo amd64. Attached is a piece of a screenshot from tuxracer. Check out the vertical black line in the sky in the background. That's an edge of a sky polygon. Let me know what other info i can provide. That's a known bug in those applications. I submitted a fix to ppracer some time ago, which was merged. If you can name other applications, I suppose authors will be interested in patches as well. Tuxracer is not maintained though, so there is nowhere to send a patch. FYI, all this was started by a non-conformant behaviour of the clamping mode on nvidia drivers, and people not testing with other drivers than the proprietary nvidia ones (which don't have this issue because of their buggy clamping behaviour). And now nvidia doesn't want to fix that behaviour, because that would expose those bugs (although some versions of the windows driver have a configuration checkbox to enable conformant clamping behaviour). Stephane - 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] glViewport()
Dawid Gajownik wrote: Hi! Hi, I have finished documenting glViewport() and glScissor() functions → http://fedora.pl/~gajownik/nouveau/glViewport_and_Scissor_NV17 Very nice ! Output of glViewport depends on 13 variables (I still haven't figured out three of them) so it took me some time :/ I've been using this simple program to test the algorithm → http://fedora.pl/~gajownik/nouveau/Viewport.c What do you think about renaming NV10_SET_VIEWPORT_DIMS to NV10_SCISSOR? If you execute glEnable(GL_SCISSOR_TEST) function, NV10_SET_VIEWPORT_DIMS changes dimensions of scissor box (not viewport ones). We'd have to make it clear that it's used for both viewport and scissor... so maybe NV10_SET_VIEWPORT_SCISSOR_DIMS ? I work now on functions from chapter 4 from this ebook → http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf :) http://fedora.pl/~gajownik/nouveau/glAlphaFunc_NV17 http://fedora.pl/~gajownik/nouveau/glEnableDisable_NV17 Good ! Stephane --- 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=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] glViewport()
Dawid Gajownik wrote: Dnia 04/30/2006 02:47 PM, Użytkownik Stephane Marchesin napisał: What do you think about renaming NV10_SET_VIEWPORT_DIMS to NV10_SCISSOR? If you execute glEnable(GL_SCISSOR_TEST) function, NV10_SET_VIEWPORT_DIMS changes dimensions of scissor box (not viewport ones). We'd have to make it clear that it's used for both viewport and scissor... so maybe NV10_SET_VIEWPORT_SCISSOR_DIMS ? OK :) BTW How should I name files with documentation? Are there any rules or can I use function's name? Which suffix should I add - family name (NV10) or chipset name (NV17)? Looking at existing files in doc module I see a discrepancy so I don't know which way should I choose. We're not sure how functionality generalizes among the cards in a given family. So please mention the precise chipset you used somewhere. We can always generalize later on. Stephane --- 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=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: nouveau: how does it relate to the free beos driver?
Paul Wise wrote: Hi all, [I'm not subscribed, please CC me] I'm wondering how nouveau relates to this free nvidia 3D driver for beos. Perhaps you could use code from it? I think it is utah-glx related. http://be-hold.blogspot.com/ Hi, Yes, we know about that 3D driver. I'm in contact with the author and we are exchanging ideas/findings :) Also, the 2D driver from haiku is quite good and has more features than our nv DDX. Stephane --- 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: nouveau: how does it relate to the free beos driver?
Michael Schreckenbauer wrote: Hello, Am Mittwoch, 26. April 2006 17:02 schrieb Stephane Marchesin: Paul Wise wrote: Hi all, I'm wondering how nouveau relates to this free nvidia 3D driver for beos. Perhaps you could use code from it? I think it is utah-glx related. http://be-hold.blogspot.com/ Hi, Yes, we know about that 3D driver. I'm in contact with the author and we are exchanging ideas/findings :) Also, the 2D driver from haiku is quite good and has more features than our nv DDX. that's really interesting news to me :) Am I correct, that newer GeforceFX are not (yet?) supported by this driver? Is there anything I can do to help with this? I have a few nvidia cards here. Riva128, TNT, TNT2, Geforce, Geforce3, GeforceFX 5900XT and GeforceFX 6800GT. In addition, I don't fear to install some really experimental stuff on some of the machines these cards are builtin ;) Well, the BeOS driver only support up to nv10 (geforce 1, geforce 2 and geforce 4 mx). We're working on getting nv20 and up to work (and getting nv10 to work in TCL mode). If you feel like working on that, here is what to do : - get renouveau, the tool to figure out commands from http://nouveau.sourceforge.net/ - look at http://nouveau.sourceforge.net/required-functionality.html and decide a feature/card to figure out (please avoid nv03 for now) - send OpenGL commands that achieve what functionality you want, and try to make sense of the output Also, we hang in #nouveau, irc.freenode.net if you're irc'ing. Stephane --- 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] input range
Dawid Gajownik wrote: Hi! Hi, I was told on fedora-devel-list about nouveau project and I would like to help somehow ;) Although I don't have good programming skills, renouveau tool is quite easy to use so I could try to guess how some OpenGL commands work (examples in doc directory are really usefull, too). I've started with glViewport() function. My question is: should I check all possible input data including negative values? Negative values are forbidden by the spec, so the behaviour is to issue an error instead of sending commands. The common codebase in mesa does that already, so we don't need to figure that out. I tried that and it's more complicated than examples in doc/state ;-] Please take a look at file state_NV17 from http://fedora.pl/~gajownik/nouveau/ (it's not finished yet). Is that normal that first glViewport() invocation is run three times (or at least it looks like this - please see glViewport_1 file) and subsequent ones only once? I also noticed that if I pass negative width the second invocation of glViewport() is not run (file glViewport_2). renouveau does not see it or it's really not executed? It's not executed, since it's invalid. I would also like to thank you for trying to make Open Source 3D driver for nVidia cards! I've been waiting so long for it... BTW Can't you move your CVS server somewhere else? Anonymous access on sf.net does not work (actually, it works but files are outdated). I use daily packages but it's not the same :/ Well, the advantage of sf.net is that I can give CVS access to lots of people. Btw, you should really give me your sf.net id so that I can add you to the project. That way you could commit your stuff as well (and you wouldn't have to use anonymous acces any more :) Stephane --- 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=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Texture replacement policy and occlusion queries
Hi, I was considering how complicated it can be to implement a texture replacement policy, and then I had the following idea : we could make use of hardware cocclusion queries on cards that support them to determine actual texture usage and thus have a good texture replacement policy. Here is a simplified view of how this could work : - a usage counter is added to each texture - each time a texture is bound, a query is started - each time a texture is unbound, the counter is read back and added to the corresponding texture counter - after a number of frames, we are able to compute the number of pixels actually contributed to by each texture, and thereby determine texture usage on the fly. Then, we can use this information to move textures to/from agp/video ram accordingly. Given that occlusion queries are virtually free (at least when supported by the underlying hardware) I think this approach could work quite well. It is also possible to extend it to multitexturing without too much trouble. What do you think ? Stephane --- 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=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Philipp Klaus Krause wrote: Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. It could be the mipmap selection offset that fglrx applies to textures. There's a setting for this reg on r200 (see the R200_EMIT_PP_TRI_PERF_CNTL reg), it probably applies to r300 too. Stephane --- 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=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRM/Mesa Patches
khaqq wrote: On Tue, 06 Dec 2005 13:13:35 +0100 Roland Scheidegger [EMAIL PROTECTED] wrote: vehemens wrote: Posting my latest DRM and Mesa patches in case they should prove useful to anyone else. They are to head as of early Saturday. I moved the CP idle outside the while loop in radeon_state.c. I think it may apply to the R300 as well as there is an if R300 idle command in the Xserver RADEONEnterServer function. I have not tried removing the DRM changes since adding the Mesa change. Just sticking with something that doesn't lockup. I'm still thinking it just doesn't really make sense the rv250 would need the pairwise tex emit. Apparently, it's not needed for a lot of people (my own rv250 If never locks up like that) so I guess there's more to it. One reason which comes to mind why some cards lock up and others don't (apart from timing differences due to cpu/chipset) would be different bioses on the cards - there have been issues like that wrt to cache programming in the past. Probably not. My FireGL8800 used to crash a lot about one year ago while ajax' never crashed. And as far as I can tell, there is only one BIOS for that card. ( http://www.techpowerup.com/bios/?search=8800Submit=Search ) BTW, a friend of mine reports 6.8.2 stable with his 8800, while it did not work on my machine. That site is probably far from exhaustive. I know at least two bioses for the 7000 that are not listed there. And I've seen radeon caching issues solved by bios updates in the past. Also, you don't happen to have fast writes enabled ? Stephane --- 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=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
Philipp Klaus Krause wrote: I hvae removed GL_EXT_cull_vertex from my patch, since Brian wants to remove it from Mesa, too. Since the r128 doesn't have hardware tcl all interesting features of Mesa's software tcl should be exposed. This patch adds support for GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_EXT_multi_draw_arrays, GL_MESA_pack_invert, What is the point of advertising GL_MESA_pack_invert if it's not implemented ? Stephane --- 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: r128 software features patch
Philipp Klaus Krause wrote: Stephane Marchesin schrieb: What is the point of advertising GL_MESA_pack_invert if it's not implemented ? Stephane According to extensions specification this extension's main purpose seems to be making application developers life a little bit easier, just like GL_MESA_window_pos/GL_ARB_window_pos does, not exposing hardware features. So I thought it might be useful to advertize this one. The i915 driver does the same. No, the intel driver implements it. Stephane --- 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: Kernel / user interface for new memory manager
Michel Dänzer wrote: Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. I still think 'we may not succeed 100%, at least in the short term' is a bad excuse for not trying, but that seems to be mostly me. Sure, but I have not seen any other design that Ian's. In particular, his design adresses performance concerns by avoiding going into the drm for each allocation. So, if someone knows how we can have both security and performance, I'm all ears. Stephane --- 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
Stephane Marchesin wrote: Now, there is one question that sounds to me like it will have implications over the whole memory manager design : do we want to enforce video memory ownership ? Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. - regions that are marked as preserve have a matching backing store region in system ram. That region is made of pinned pages. Stephane --- 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
Michel Dänzer wrote: You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. Yeah, I don't expect it to be prohibitive; we're basically doing just that for Radeons already. Well, right now any app can use BITBLT_MULTI to read/write to others video memory, for example. Not that it's a problem to me, or that I wish to solve it by auditing all the dri drivers to add the necessary checks :) As for the performance, what is done right now (checking that the offset falls within a given region) is some orders of magnitude simpler than what we would have to do (checking the offset against all regions allocated by a process). Also, with the current log design for the memory manager, it is possible for a rogue process to make the log wrap and not call the force_log_update ioctl, thus being able to create some kind of race condition where the drm believes it still owns the memory but another process has allocated it. 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... Stephane --- 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
Alan Cox wrote: 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. Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. 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. Protecting a statically assigned command queue is one thing (something similar to what's currently done on radeon would be sufficient), protecting dynamically allocated video memory is another. 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. Actually, the long term idea is to have both dri and ddx allocate from the same memory pool. So we can't rely on texture handles for that. Stephane --- 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
Ian Romanick a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There's been quite a bit of discussion about this on #dri-devel the past few days. I thought I'd write up a quick summary and post it to the list. I know that there are a lot of interested parties that are on the list, but who don't hang out in #dri-devel. :) As described in an old message[1], the new memory manager will be partially in the kernel and partially in user space. The discussions in IRC have focused on the interface between the two. Listed below are the functions that have been discussed. The names are just made up. initialize_pool - Initialze a new memory pool. This will be called once for each memory pool (e.g., on-card, AGP, PCI, etc.). get_pool_state - When a new process starts up it needs to know the state of a pool. That is, it needs to know which regions are allocated or not allocated. Since all allocations / frees are written to a log that is stored in a circular buffer, it is possible for the log to wrap around between times when a given processes the log. In that case the process will also need to use this function. force_log_update - The kernel updates its view of memory periodically when processes call into it. It is possible (though very unlikely) that a process could wrap the log between these occurances. The process can detect this and, before wrapping the log, call this function so that the kernel can update its view of memory. backup_region - Regions can be marked with a preserve bit. This means that the contents have to be saved before the memory can be reclaimed. backup_region instructs the kernel to do this for a specified portion of a region. restore_region - Restores the contents of a previously backed-up region to a new location. Depending on how backup_region is implemented, this function may not be necessary. As you said on IRC, this might not be needed. alloc_id_block - Each region is tracked by a unique ID. This function allocates a block of these IDs to a process. They will be automatically reclaimed if the process dies. release_id_block - Releases a block of previously allocated IDs. Now, there is one question that sounds to me like it will have implications over the whole memory manager design : do we want to enforce video memory ownership ? Stephane --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Latest savage snapshot doesn't work
Felix Khling a crit : I haven't changed anything in the Savage DRM in a while. Must be some change in the generic drm module. I won't be able to look into this. Does the oops below ring a bell, anyone? I think that's the same issue I have (https://bugs.freedesktop.org/show_bug.cgi?id=2418) It disappears when you play with your kernel .config, although I didn't get around to find out why yet. You may want to try insmoding other card-specific modules (for example radeon.ko) to check whether that's the same issue. Stephane --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
