Re: [Nouveau] [PATCH] drm/nouveau: reduce usage of fence spinlock to when absolutely necessary
The update of last_sequence_irq is still racy with this patch... So let me explain: - non-interrupt context starts reading last_sequence_irq - irq happens in the middle (because it is not an atomic read, it's possible, albeit it doesn't happen on x86 so just saying it works on my x86 isn't enough) - last_sequence_irq is modified in interrupt context - second half of last_sequence_irq happens in normal context and results in a bogus value Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Why do we disable local IRQ around nouveau_fence_update?
On Thu, May 27, 2010 at 22:47, Ben Skeggs skeg...@gmail.com wrote: On Thu, 2010-05-27 at 17:55 +0300, Pekka Paalanen wrote: On Wed, 26 May 2010 23:24:57 +0200 Maarten Maathuis madman2...@gmail.com wrote: For NV04 i can understand, since it's irq driven fences, so let's split the question. NV10+: can we reduce it to just spin_lock? I don't know the answer, but I know the theory: if there is any path, that can take the spinlock from an interrupt service path, then you must use the irq-safe version everywhere. We could, the interrupt-based path is currently only used on really old chips that don't have REF_CNT. NV04: can't we rely on a normal spin lock and add it as well in nv04_graph_mthd_set_ref? So if NV04 fences are driven by irqs, and the ISR needs to take the lock, then no, you cannot revert to irq-unsafe spinlocks. I'm not sure how it relates to ISR bottom halves, though. Note, that also irq-unsafe spinlocks disable preemption, which might be enough to disturb audio. The spinlock was actually only ever meant to protect the list itself and not the sequence counters. I've attached a patch removing the spinlock use everywhere except when we're actually going to touch the pending list, I think last_sequence_irq is still safe as the NV04 fence IRQ handler is the only writer. That would mean the write has to be atomic everywhere though. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Why do we disable local IRQ around nouveau_fence_update?
On Thu, May 27, 2010 at 23:03, Stephane Marchesin stephane.marche...@gmail.com wrote: On Thu, May 27, 2010 at 22:47, Ben Skeggs skeg...@gmail.com wrote: On Thu, 2010-05-27 at 17:55 +0300, Pekka Paalanen wrote: On Wed, 26 May 2010 23:24:57 +0200 Maarten Maathuis madman2...@gmail.com wrote: For NV04 i can understand, since it's irq driven fences, so let's split the question. NV10+: can we reduce it to just spin_lock? I don't know the answer, but I know the theory: if there is any path, that can take the spinlock from an interrupt service path, then you must use the irq-safe version everywhere. We could, the interrupt-based path is currently only used on really old chips that don't have REF_CNT. NV04: can't we rely on a normal spin lock and add it as well in nv04_graph_mthd_set_ref? So if NV04 fences are driven by irqs, and the ISR needs to take the lock, then no, you cannot revert to irq-unsafe spinlocks. I'm not sure how it relates to ISR bottom halves, though. Note, that also irq-unsafe spinlocks disable preemption, which might be enough to disturb audio. The spinlock was actually only ever meant to protect the list itself and not the sequence counters. I've attached a patch removing the spinlock use everywhere except when we're actually going to touch the pending list, I think last_sequence_irq is still safe as the NV04 fence IRQ handler is the only writer. That would mean the write has to be atomic everywhere though. Blah, of course the *read* has to be atomic, not the write... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv20tcl and renouveau questions
On Thu, Apr 22, 2010 at 02:59, Xavier Chantry chantry.xav...@gmail.com wrote: First some data errors I get with both nv20 exa and nv20 dri/mesa. 1. RT_FORMAT LINEAR + X8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x0105 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x0105 LINEAR + A8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x0108 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x0108 The only value I found in renouveau dump was 0x0128. You need to have renouveau create other buffer formats... otherwise you'll only get 0x128 indeed. Let's look at renouveau.xml nv20 reg32 offset=0x0208 name=RT_FORMAT type=bitfield bitfield name=TYPE high=11 low=8 type=enum enum_name=nv40_rendertarget_type/ bitfield name=COLOR high=4 low=0 type=enum enum_name=nv40_rendertarget_color_format/ /reg32 Nothing for bit 5. Looking at dri/mesa : case MESA_FORMAT_XRGB: return 0x05; case MESA_FORMAT_ARGB: return 0x08; case MESA_FORMAT_RGB565: return 0x03; case MESA_FORMAT_Z16: return 0x10; case MESA_FORMAT_Z24_S8: return 0x20; Does that mean that color only goes from bit 0 to 3, and zeta is bit 4-5. Unlike nv30 where color goes from 0 to 4, and has zeta on 5-6 ? Probably yes. Testing in renouveau will tell you. On nv20, 0x10 and 0x20 is valid, but not 0x40. And it seems nv20 dri also cause data errors because it does not always set zeta with 0x10/0x20, it only does that in depth/stencil case. 2. TX_FILTER(0) MIN NEAREST + MAG NEAREST Ch 1/7 Class 0x0597 Mthd 0x1b14 Data 0x0101:0x0101 For that one, I found the 0x2000 value both in nv20 renouveau dump and nv30 exa. nv30 exa documents it as engine lock. Anyway idea what that is, and how to add it to renouveau.xml ? bitfield name=ENGINE_LOCK high=13 low=13 type=boolean/ ? It's real name is not ENGINE_LOCK, we don't know what this bit is exactly. 3. And finally, is this name difference RT_PITCH / COLOR0_PITCH between nv10/nv20 and nv30/nv40 normal ? I saw many naming inconsistencies that were more obvious, the worse part is probably between nv30 and nv40. But not sure about that one, if 0x20c is the same method or a different one. nv10 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=RT_PITCH type=bitfield reg32 offset=0x0210 name=COLOR_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ nv20 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=RT_PITCH type=bitfield reg32 offset=0x0210 name=COLOR_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ nv30 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=COLOR0_PITCH type=bitfield reg32 offset=0x0210 name=COLOR0_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ nv40 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=COLOR0_PITCH type=int/ reg32 offset=0x0210 name=COLOR0_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ Yes those should be renamed to RT_* Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gart to vram/vram to gart transfers broken on NVS 140M
On Thu, Apr 22, 2010 at 03:13, Martin Peres martin.pe...@free.fr wrote: Hi Nouveau folks, I've been encountering some corruption on pixmaps for a while now, and it seems like the problem comes from the DFS/UTS (Download From Screen / Upload To Screen). In fact, I'm pretty sure the problem comes from there as screenshots are garbled and so does a few more things. I may have time to dig this up, where should I start, is there some documentation on the NVS 140M ? Where is the gart2vram code located ? Do you have any idea of where could be the problem ? If you really think that's UTS/DFS, edit nouveau_exa.c and disable them (change the UTS/DFS functions to return FALSE, that'll trigger fallbacks to sw copying). Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau_class.h
On Thu, Apr 8, 2010 at 23:51, Ben Skeggs skeg...@gmail.com wrote: So, with all the nouveau_class.h changes lately it's become rather difficult to keep libdrm synced up with a particular mesa version. This is much like what happens when we break our kernel ABI, but on a far more regular basis so it has a larger impact. I'm proposing we drop nouveau_class.h from libdrm again, and move it back to the ddx and mesa trees where it can be updated at the same time the code that uses it is. Any objections / other suggestions? Agreed. We don't need more interfaces, we need less interfaces. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [radeonhd] Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
On Sun, Mar 28, 2010 at 18:39, SpliFF spl...@warriorhut.org wrote: On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin Simpson wrote: Since neither you nor Andrew are lawyers, I would kindly ask that you refrain from attempting to provide legal advice. :3 If you know I'm not a lawyer (and my nick should be the first clue) then it isn't an issue is it? As for Andrew you'll have to ask him that yourself. Since it's also clear I'm not a mesa3d developer you assume no legal responsibility for what I say either and you are under no responsibility to listen. Which is all irrelevant anyway because proposing to create a new invention is not legal advice; it's an engineering suggestion. I describe the patent claims and Andrews interpretation of patent law only to emphasise things that a hypothetical new invention should *not* do. The scant legal advice that *has* been obtained suggests that the current course of action, wherein S3TC is not advertised without the aid of an external library or a configuration option force-enabling it, is the best course of action. I for one would prefer to have firsthand legal advice before making any changes, although I am not a lawyer and cannot provide legal advice. Solves nothing other than push the legal burden onto someone else (distributions) who further push the burden to the end-user. All of which makes it harder to use. As far as I can tell the official site of the external project claims the project is unmaintained and at any rate it's rather unpopular with certain distributions for reasons that should be obvious. I'm certainly not sugesting that knowingly infringing material be added to mesa3d. What I'm suggesting is that some resources be made available to write a new *non-infringing* decompressor and that it seems likely the community may have overestimated the difficulty of the task. I often wonder if the OSS community isn't becoming a victim of its own FUD. If we need lawyers before writing code then we can't write ANY code and we might as well all do something else. I want to reiterate that it is my belief (as in non-legal opinion) that the s3tc patent does not cover the s3tc format itself, or even specific algorithms. What it covers appear to be specific methods that can be used to encode it and some steps that can be used to decode it. The issue is whether those claimed steps are the ONLY way of achieving an acceptable result and I honestly don't think they are. You are free to form your own opinion on that point. Then again if the community plays ostrich and assumes the problem is now solved - and worse concludes that any discussion of it is heresy - then how can a new invention be developed (at least collaboratively)? Unfortunately I lack the indepth knowledge of mesa3d internals and s3tc processing requirements required to invent such a thing myself. I made a similar proposal a couple of years ago. Basically the patent explicits the vector quantization scheme, and I wanted to go with another vector quantization scheme instead. Also that would probably mean better overall compressed texture quality (the quantization algorithm used in the patent is approximate to say the least) but longer compression times. The core issue is that some people do not want to see this code in mesa in whatever form, because they're afraid of lawsuits. Rumour has it that VIA told them that they would sue. And the same things happened with SGI for the float patents by the way. So blame VIA and SGI for their anti-oss behaviour instead. For example next time you see a motherboard with a VIA chipset, think twice... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] making 0.0.16 into 1.0.0
So, after discussion on irc, here is an idea/proposal. We could flag the upcoming couple of months (two months sounds like enough?) as the nouveau DRM stabilizing timeframe. Everything that we think should go into the DRM (basically everything which we want to go in and can be achieved in that timeframe) goes in. And then we declare that our first stable API ever. And then we party. So, does that sound like a plan? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] making 0.0.16 into 1.0.0
On Thu, Mar 4, 2010 at 17:23, Dave Airlie airl...@gmail.com wrote: So with all this ongoing Linus crap I'm going to be brave and ask for reasons why 0.0.16 kernel API can't become 1.0.0. Pros: All old userspace compatibility is gone. No more UMS cruft to support. Something can be shipped on distros at last, people get to use the driver. 3D drivers exist and use the interface, there is an investment in these already. Reasons against: (I'm making these up, feel free ack/nack/flesh out/add more etc). We haven't finished 3D drivers yet so the interface may still need changes? TTM sucks? Userspace command-submission for ever? I don't like versioning anything ever? Yeah, we definitely need more performance tuning on the 3D driver and video playback side. Otherwise we could end up shipping something that has no chance of sanely evolving into a fast enough driver. The issue is right now we are only barely scratching the surface of the performance issues. So my current answers to my list of cons is: Adding new faster interfaces for 3D drivers shouldn't be a major problem, if its just a matter of making the current APIs saner. You quickly handware this, but the problem is there is no way to be sure about it. If it was that simple we could have made a stable release many moons ago. Maybe the problem stems from some TTM bit, maybe it's a user space interface which is too heavy. There is no way to know right now. If you are going to write a UCS/non-TTM driver you are going to have to do major changes all over the stack, in theory a kernel CONFIG option to enable version 2 of the interface and drop version 1 would be an option at that time. Or even a boot option to select between which one you want. I would forsee a UCS/non-TTM driver needing to rewrite quite a lot of userspace, in fact probably all of it. I haven't seen anyone actually start or commit to working on such a beast, and I'd reckon its probably a 1-2 year job, GEM took over a year and it was arguably simpler. I'm not seeing the point of sitting in a holding pattern for that length of time just in case its better. The future is always going to be better. Yes for a full GEM replacement that is probably true, but I think we should aim for something TTM based with decent performance. And we're really not remotely there yet. Having each driver carry the same suballocator? Come on... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2.6.33 vs. NVIDIA GForce GT 220
On Tue, Jan 26, 2010 at 01:47, Pavel Machek pa...@ucw.cz wrote: Hi! I tried enabling staging nvidia driver on GT220, but apparently driver does not know about it. Unfortunately, I have one of those cards here. (I wonder... is there better mailing list? MAINTAINERS only lists linux-fbdev) The list is nouv...@lists.freedesktop.org. And driver knows about GT220 just fine, I've been using it for a month or two on GT220 already. Don't bother Perhaps nouveau@lists.freedesktop.org should be added to MAINTAINERS? about the supported cards lists in xf86-video-nouveau or wherever else, the driver will happily bind to any nvidia video card with known generation, even if nobody has seen that precise model before. Unfortunately, the driver does not seem happy: Jan 18 12:56:38 pma kernel: [ 0.491073] nvidiafb :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Jan 18 12:56:38 pma kernel: [ 0.491507] nvidiafb: Device ID: 10de0a20 Jan 18 12:56:38 pma kernel: [ 0.491546] Chipset is 10de0a20 Jan 18 12:56:38 pma kernel: [ 0.491584] nvidiafb: unknown NV_ARCH Jan 18 12:56:38 pma kernel: [ 0.492119] vga16fb: initializing Hmm, but this is not nouveau, this is nvidiafb... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Porting nouveau/ttm/drm to FreeBSD/OpenSolaris
2010/1/23 C. Bergström cbergst...@pathscale.com: Hi all, One of our (PathScale) engineers is planning to port nouveau and all dependencies to OpenSolaris. We have two routes we can take and would like some feedback from the community. 1) There's an existing drm without ttm that was done by the FreeBSD developers. Would anyone from the fbsd team like to go over some of the trouble they've had in porting ttm? 2) The engineer doing the work is much more familiar with Intel GEM and has said the following (which I don't honestly know if it's true or not) a. Intel GEM surely will continue to be supported b. It's already available on OpenSolaris c. More portable than ttm d. GEM doesn't have support for nvidia cards and is missing some important features. (For OpenSolaris he says those can be added and is less effort than porting ttm) e. Is probably better performance compared to ttm How do you plan to handle real video memory in GEM? Will you add support for it in the GEM common code? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC] nouveau: Add basic i2c sensor chip support
On Fri, Nov 20, 2009 at 21:02, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Nov 20, 2009 at 01:59:37PM -0600, Robert Noland wrote: On Fri, 2009-11-20 at 18:43 +, Matthew Garrett wrote: This one works better, including some amount of support for the internal GPU sensor. It seems to give reasonable results on all the cards I have here. So, I obviously have concerns/objections to allowing GPL code into drm. Especially, since this code doesn't do anything interesting or innovative that I can see. It just reads registers via i2c... I mean how else would you do it? It contains code cut and paste from nvclock (a GPLed codebase) and uses functions that are specific to the Linux kernel. I don't have the legal expertise to be able to claim it's not a derived work. An alternative would be to ask Roderick if he's ok to relicense the bits from nvclock. Doesn't look like a lot from what I can see. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix WITHIN macro off by one
On Fri, Sep 18, 2009 at 20:15, Pekka Paalanen p...@iki.fi wrote: Equality in x = y + z is already out of range. X must be stricly less. Yeah, I did that back when the SIZE defines were, say, 0x1fff instead of 0x2000 so this was required. Seems like the size defines changed, but the WITHIN macro wasn't updated. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] DRM changes
On Mon, Mar 9, 2009 at 23:23, Maarten Maathuis madman2...@gmail.com wrote: Questions: A tree based on what? (linus, drm-next, etc) I would follow drm-next, but I don't think it is very relevant at this point, since anyway drm-next periodically merges to linus. If there are reasons to choose one over the other, I'm interested in hearing them. What happens to shared-core? It will probably meet its creator. Opinions (assuming this happens): I'd do a branch for each kernel version (or less if needed), and let people who care cherry-pick fixes. Yeah that's what I initially thought, but Pekka said you could also get an out-of-tree build from a full kernel tree. So that's the two paths to explore. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] DRM changes
Hi, As part of aiming at upstreaming our code, I suppose we have to discuss the DRM situation a little. In order to aim for merging, I think we'd better be working on a linux kernel tree layout. And considering we're technically the only ones still working in drm.git, it doesn't really make sense to keep doing that for the sake of sharing code with other drivers. As we discussed on irc, there would be multiple changes related to this: - we move to a linux kernel-like tree, that should make it easier when upstreaming the code. - this new tree is hosted in freedekstop.org in the nouveau/ git so we don't need additional accounts for everyone all around and people can keep pushing things (even better, all nouveau people can push to the drm, which used to require mesa rights before) - we keep a(some) branch(es) in the tree for backwards compat with older kernels. Either in the form of separate kernel versions including nouveau, or in the form of an out-of-tree-compilable drm/nouveau module. So, does that plan sound sane? Do you have better plans? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] running x.org on powerpc64 with nvidia6200
On Sun, Feb 15, 2009 at 06:18, Dave Airlie airl...@gmail.com wrote: On Sat, Feb 14, 2009 at 8:32 PM, Stephane Marchesin marche...@icps.u-strasbg.fr wrote: On Sat, Feb 14, 2009 at 10:12, aik aik.r...@gmail.com wrote: Stephane Marchesin wrote: How many PCI domains does that machine have ? Current libpciaccess is broken, in that PCI cards only work in the first domain. So the solution is to put the card in a slot from the first domain if possible. You are screwed otherwise (well, you could replace the hardcoded first domain in pciaccess with the right domain and it might work, I don't know...) No way. There are 6 domains and the first does not have any connector... But this libpciaccess - is it linux lib or nouveau lib or x.org lib? It's an X.Org library. If you look there is a 0 hardcoded somewhere for the domain - can't recall where exactly offhand though. Most people aren't affected because there is usually a single PCI domain on PC/x86... I don't think thats true, pciaccess handles domains fine. DRM on the other hand not so well, I think you get to play with the bits of the drm that match buses. Also be careful X's BusID are b...@domain:func:dev not at all obvious. Yeah I asked benh and he said the domain problem in pciaccess was indeed fixed, but in the DRM not so much... He also said he had some patches though :) Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] running x.org on powerpc64 with nvidia6200
On Sat, Feb 14, 2009 at 10:12, aik aik.r...@gmail.com wrote: Stephane Marchesin wrote: How many PCI domains does that machine have ? Current libpciaccess is broken, in that PCI cards only work in the first domain. So the solution is to put the card in a slot from the first domain if possible. You are screwed otherwise (well, you could replace the hardcoded first domain in pciaccess with the right domain and it might work, I don't know...) No way. There are 6 domains and the first does not have any connector... But this libpciaccess - is it linux lib or nouveau lib or x.org lib? It's an X.Org library. If you look there is a 0 hardcoded somewhere for the domain - can't recall where exactly offhand though. Most people aren't affected because there is usually a single PCI domain on PC/x86... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] running x.org on powerpc64 with nvidia6200
2009/2/13 Alexey Kardashevsky aik.r...@gmail.com: I am newbie in this topic and I have problems trying to bring x.org up on the hardware I have: IBM QS22 BladeServer (PowerPC64 architecture) with PCI-Express connected nVidia 6200 video card. OS: Fedora 10-ppc: Linux localhost.localdomain 2.6.27.5aik #1 SMP Tue Feb 10 14:55:56 EST 2009 ppc64 ppc64 ppc64 GNU/Linux How many PCI domains does that machine have ? Current libpciaccess is broken, in that PCI cards only work in the first domain. So the solution is to put the card in a slot from the first domain if possible. You are screwed otherwise (well, you could replace the hardcoded first domain in pciaccess with the right domain and it might work, I don't know...) Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] nv50: initial bits for shadowfb
On Thu, Feb 12, 2009 at 23:56, Maarten Maathuis madman2...@gmail.com wrote: - Fallbacks on the frontbuffer still need to be handled. --- Why are you posting this again ? It's not really better than the last time, still a lousy workaround. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Bug 19491] S-video composite output
On Wed, Jan 14, 2009 at 15:29, Stefan Monnier monn...@iro.umontreal.ca wrote: http://bugs.freedesktop.org/show_bug.cgi?id=19491 --- Comment #4 from Younes Manton youne...@gmail.com 2009-01-11 11:03:32 PST --- (In reply to comment #3) Is there something I can do to help get TV-out support? Unless you want to try reverse engineering it yourself you just have to wait until someone has the time and motivation to do it. I haven't done any coding in an Xserver or anything even remotely similar, but if someone is willing to coach me, I'd be interested in giving it a try. Sure, I guess you could drop by on irc and ask. We are usually friendly with people willing to make an effort :) FWIW I would start this with a trace of the binary driver or looking at the bios (it depends on the card you have)... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce MX4 - DMA queue hang
On Fri, Oct 24, 2008 at 18:35, Andrew Betts [EMAIL PROTECTED] wrote: (Dup message.. sorry pekka... i meant to reply to the list.) I can confirm nvidiafb is not loaded, nor are the nvidia proprietary drivers. Here is, what I hope is, the relevant section from kern.log: http://www.jasp.com/nouveau/crash_log.241008.txt That kernel log is incomplete. Can you provide a full (from boot) log ? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce MX4 - DMA queue hang
On Fri, Oct 24, 2008 at 19:38, Andrew Betts [EMAIL PROTECTED] wrote: That kernel log is incomplete. Can you provide a full (from boot) log ? Sure. http://www.jasp.com/nouveau/kern.log.241008.txt Okay, I wanted to ask for a debug kernel log, sorry :) (before starting X use modprobe drm debug=1) Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Linux drivers for GoForce 5500 on g900
On Mon, Aug 25, 2008 at 1:28 PM, Ralovich, Kristóf [EMAIL PROTECTED] wrote: Hi Stephane, in this http://lists.freedesktop.org/archives/nouveau/2008-April/001390.html mail you mention, I am quoting we have most of the technical documentation for the GeForce 5x00 chips. Is this doc available somewhere for the general public? Yeah, although it's scattered around: - 2D/3D accel bits are at http://nouveau.cvs.sourceforge.net/nouveau/renouveau/renouveau.xml?revision=1.237view=markup - the regs are at http://nouveau.cvs.sourceforge.net/nouveau/rules-ng/databases/nvregisters.xml?revision=1.48view=markup - some things are still only documented in the driver code itself, but patches correcting that by fixing the above 2 are welcome :) Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [BUG/PATCH] x86 mmiotrace: dynamically disable non-boot CPUs
On Wed, Apr 16, 2008 at 6:59 PM, Pekka Paalanen [EMAIL PROTECTED] wrote: On Wed, 16 Apr 2008 13:46:09 +0200 Ingo Molnar [EMAIL PROTECTED] wrote: * Pekka Paalanen [EMAIL PROTECTED] wrote: we should fix this restriction ASAP. Forcibly dropping to UP will cause mmiotrace to be much less useful for diagnostic purposes of Linux Ok, how do you propose we solve this? I have asked the question before, and then I had two ideas. Well, the first one was actually your idea (so I hear) to solve the same problem for kmemcheck. - per-cpu page tables - instead of single-stepping, emulate the faulting instruction and never disarm pages during tracing. (Use and modify code from KVM.) I don't believe either of these is easy or fast to implement. Given some months, I might be able to achieve emulation. Page tables are still magic to me. yeah - it looks complex. Not a showstopper for now :-) but given that Xorg is usually just a single task, do we _really_ need this? We're not tracing Xorg at all. Mmiotrace still cannot catch accesses originating in user space. It is tracing MMIO accesses from within the kernel, and this means that IRQ services and device syscalls may be accessing the hardware at the same time. Vblank interrupts happen quite often, some GPU commands are actually emulated in kernel via interrupts and whatnot. The nvidia proprietary kernel blob is many times bigger than my bzImage! (A simple X startup and quit creates in the order of 1-2 million MMIO events.) As do we really need this, I think it might save a lot of head scratching when someone is reverse engineering a feature and gets every time a different trace due to some events being missed. But this is theory. So far everyone has been tracing with UP, and this has not been a problem. I have no idea if it would make a real difference. [Recap for nouveau@ list: mmiotrace has a race on SMP, where during instruction single stepping other CPUs can run freely on the page which the faulted instruction accessed. This causes some of the simultaneous accesses to the same page of the same iomem-mapping to be missed.] It does sound very rare. Nouveau people, what do you think, can this be a problem? In the nvidia case, I don't think this would happen. The register ranges for different purposes are set apart by more than 1 page usually, so the risk of accessing a page that's been faulted in is probably extremely low. Not to mention that the design of the binary module doesn't use threads currently (only tasklets for interrupt handlers, this might be the corner case but again the interrupt handler doesn't touch the same reg families). Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GoForce 5500 Driver in Toshiba Portege G900
On 4/7/08, Arseniy Nikolaev2 [EMAIL PROTECTED] wrote: Hello, community. Hello, Several months ago Toshiba Inc. released a new communicator - Toshiba Portégé G900. All device's features are greate, but in practice things are going another way: communicator is really SLOW. Toshiba users have found that G900 is using nVidia GoForce 5500 Chip in it and it seems like it's working partially, because of an incomplete driver. We have written a petition to send to toshiba, and got more than 1200 signatures from Toshiba users. So when we sent it, we got this reply: Thank you for purchasing Toshiba Portage G900. We regret to inform you that G900 partially supports the functions which GoForce provides, though we are aware that GoForce itself supports various functions as you mentioned. That is the G900 product specifications. We acknowldge your comment and would like to reflect it to our future product to enhance our product line-up. Sincerely Yours, Mobile Communications Company Toshiba Corporation As you can see, it looks like Toshiba is not going to support us. So, what this all is about: As we know, you're producing drivers for nVidia video cards. We have the next questions: 1) Is it possible for you to produce a driver for GoForce 5500 Chip which will work on our device? As far as I know, the GoForce chips are mostly similar to their GeForce equivalents (i.e. the GoForce 5500 has similar functionality to a GeForce 5x00), so in theory a driver is doable for the common parts (video decoding, 3D) by reusing our code. However, the issue is mostly that this machine seems to use windows, while we're working on linux drivers. 2) If it is, than can you do this? Well, I don't think we'd do this. However, we have most of the technical documentation for the GeForce 5x00 chips, so I think someone with time and a windows mobile DDK could adapt it for the GoForce. You would need 3 big pieces of code mostly: - write a windows mobile 2D driver for the chip - write a gallium frontend for directX - fix/rewrite/modify our nv30 gallium backend for the GoForce and windows mobile specifics that will surely come up along the way That said: - this is a huge piece of work. We're talking probably 12-24 man-months. - you would probably drain the battery even quicker then because we don't know about the specific power saving features of that chip. 3) What donations do you want we to make for you? I guess you'll have to find someone to pick up the ball first :) Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Driver Problem with 7150M
On 4/4/08, Richi Plana [EMAIL PROTECTED] wrote: Hi, I tried using the nouveau driver that comes latest with Fedora Rawhide (xorg-x11-drv-nouveau-0.0.10-1.20080311git460cb26) on my HP Pavilion dv2000 laptop with a GeForce 7150M (PCI 10de:0531) but couldn't even get the server up. The server spit out the following log. Could someone tell me how to get things working? Sure, by using git instead of an old snapshot. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Memory use and a few other things
On 4/2/08, Clemens Eisserer [EMAIL PROTECTED] wrote: Hello, First of all thanks a lot for working on this free nvidia driver. 1.) I am using Fedora9-Beta, and on my NV17/64mb (or NV18?) powered Laptop the nouveau driver uses about 300mb RAM. Is there any way I can decrease that? This is AGP memory. It's (usually 256MB of) memory mapped into X.Org, and it's not actually used (only a small part of it for scratch usage). All drivers making use of AGP do that. 2.) Font rendering is very slow. running x11perf --aa10text I only get 40k glyphs/s. Is there any way I can improve text performance? Work on core EXA. 3.) I would like to downgrade to linux-2.6.16.60 - because a driver I need was broken starting arround 2.6.19. Will it still make sence to use nouveuau, or does it need DRI to work properly? See Pekka's Answer. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GSOC '08 hardware accelerated video decoding
On 3/28/08, Younes M [EMAIL PROTECTED] wrote: I've decided to submit an application for this. If anyone would be kind enough to read through the preliminary and give me opinions, concerns, corrections, etc, I would appreciate it very much. HTML version is here: http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml and a text version is included below. Thanks. Younes Manton younes.m at gmail Generic GPU-Accelerated Video Decoding Synopsis: The purpose of this project is to produce a video decoding solution for GPUs that are supported by the Gallium3D driver framework. The project will attempt to implement the XvMC API using the programmable pipeline of a typical GPU, thereby providing accelerated video decoding to a wide variety of hardware. Since the decoding will be implemented using the GPU's programmable pipeline, it is important to note that this solution should support all recent GPUs regardless of whether or not they include dedicated video decoding hardware. It is hoped that this GPU-based acceleration will allow for real-time play back of HD video streams on mid-range and possibly low-end hardware. The implementation will be developed and tested using Gallium3D's SoftPipe driver, a stable software reference implementation, and later on Nvidia hardware and the nouveau driver. Benefits: Video media has become a pervasive part of the computing landscape and encompasses a variety of formats and resolutions, from low-res MPEG2 streams to HD MPEG4 content. From the point of view of the end-user, accelerated video decoding offers potentially better quality, smoother multi-tasking (by way of unburdening the main CPU) and the extension of the lifespan of current mid-range and low-end hardware. From the point of view of the OSS community, accelerated video decoding will offer an incentive to the end-user to adopt open-source drivers, which have traditionally not provided significant video acceleration on the most popular GPUs. This particular project will also provide a multi-vendor solution, as most GPUs supported by the Gallium3D framework can be targeted with the same code base, including some current Nvidia hardware via the nouveau driver, AMD/ATI hardware, and Intel hardware, amongst others. Although there are plans for a gallium ATI driver, there is nothing concrete ATM. But it's only a matter of time. Deliverables: The deliverables for this project have been organized into two categories: the minimum set of deliverables that would make this project worthwhile for all involved (must-haves), and a larger set of goals that would make good contributions to the community and offer greater benefit to the end-user (nice-to-haves). Must-Haves: * An XvMC implementation that handles the color space conversion (CSC) and motion compensation (MC) stages of the video decoding pipeline. These two stages represent the bulk of the processing and are good candidates for being handled by the GPU. This should allow for real-time play back of HD video streams according to [1]. As part of this goal it is expected some work will have to be done with the nouveau driver to address possible bugs and add required functionality. * Handling of the inverse discrete cosine transform (IDCT) stage of the video decoding pipeline. This stage does not map optimally to the GPU pipeline but represents a large percentage of the processing and would also allow for the preceding stage (inverse quantization - IQ) to also be handled by the GPU without introducing an extra GPU-CPU-GPU round trip between the IQ, IDCT, and MC stages. XvMC was originally intended to handle the MC stage, but has been extended to support IDCT. A preliminary timeline with milestones is presented below: Preliminary research experimentation - April weeks 1 2 mplement CSC with SoftPipe - April weeks 3 4 Implement MC, IDCT with SoftPipe - May to mid-June (1) Preliminary hardware research experimentation - June Test with real hardware, add required functionality, fix bugs - mid-June to Aug (2) Bug fixes, performance testing tuning, documentation - Aug 1. Working implementation with the SoftPipe driver by mid-June 2. Working implementation with nouveau driver by end-July Nice-To-Haves: * Support for other video formats. XvMC was originally intended for MPEG2 video, but has been extended to support other formats such as MPEG4. * An implementation of the Video Acceleration API (VAAPI) which is similar to XvMC but has been designed to support off-loading more stages and more video formats. VAAPI is not currently supported widely by user applications, but this could offer incentive to application developers. * Implementation of various filters to improve visual quality. De-interlacing, de-blocking, de-ringing, bi-cubic
Re: [Nouveau] GSOC '08 hardware accelerated video decoding
On 3/23/08, Younes M [EMAIL PROTECTED] wrote: Hi Stephane, Thanks for your thoughts. I assume you mean doing the MC and CSC steps using shaders. I'm not familiar enough with nouveau at the moment to know whether or not it's complete enough to do the above, it seems like we need vertex and pixel shaders, texturing, and render target support. Yes, MC and CSC can for sure be done with shaders (we actually already do CSC using shaders for Xv on nv30/nv40 ATM). But I don't think that's the only stages we want to implement. Things like idct can also be done with shaders. In fact, except for entropy encoding (cabac, cabvlc, huffman) I'm quite confident that the whole pipeline can be put on the GPU. FWIW, newer nvidia GPUs do not even have a fixed pipe for video decoding any more, and do it with shaders (except for the entropy decoding, which has a dedicated hardware unit). As I mentioned before, I only have access to an NV30 at the moment (it looks like NV40 is the farthest along). I may look into getting an NV40 card if nouveau is far enough along to implement XvMC or VAAPI in terms of gallium3D. NV40 might be easier, but you'll probably have to fix things on the driver side in any case. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GSOC '08 hardware accelerated video decoding
On Thu, Mar 20, 2008 at 7:55 PM, Younes M [EMAIL PROTECTED] wrote: Hi, I'm considering submitting a project for this year's Google Summer of Code program that would involve making progress on hardware accelerated video decoding for the nouveau driver and wanted some feedback. I know that this isn't a big priority at the moment amongst the regular contributors, but I think it would make a good GSOC project because of it's somewhat narrow scope. I think for a lot of people 3D eye candy isn't a feature they're desperate for, they just care about a functional and efficient 2D driver, and having video acceleration would complement that nicely and entice them to switch from the Nvidia binary driver and the old nv driver long before the people who want the 3D features. I've read through jb17bsome's notes on XvMC and I think all the work he's done so far is a great head's up on what's involved. I've also read through the VAAPI page and I think that would also be a great feature to try and support given all the non-MPEG2 video content out there, it would probably entice even more people to use nouveau. The only thing I'm concerned about at this point is that the only Nvidia hardware I currently have is a GeForce FX GO 5200, so I'm not sure how much help I could really be given the limited features of that GPU. If anyone has any comments or suggestions on this, or thinks that some other area would make a better project I would love to hear your comments. Hello, I'm not sure if writing card-specific code is too much of a good idea now, given the number of existing video architectures (nvidia for example has different shaders on nv30, nv40 or nv50). Although I'm not sure of the outcome of it, it seems more interesting to write code over the gallium3D interface to achieve card-independent acceleration. This is a SoC I proposed for DRI (DRI didn't get through as a mentoring org, but we can do it through X.Org), you can read more about it there: http://dri.freedesktop.org/wiki/GSoC_2008 Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] free nvs-pass_rec on error in nouveau_shader_pass2(), nouveau_shader_2.c
Hi Roel, All your patches correct valid flaws. However, as you might have noticed, the old DRI code doesn't see much development at the moment. The reason is that we've decided to jump in the gallium3D wagon before it was even finished. So you have to know that this piece of code is currently not maintained, and that you'd have to finish it by yourself mostly. I can of course push your patches if you feel like actually working on finishing this old-scheme DRI driver. Just tell me. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Searching For The Demo
On 12/18/07, xiaodan [EMAIL PROTECTED] wrote: Recently,Novell gave the ATI Open-Source driver,but only a piece of 2D.However,the performance is unknown.There is a need of the Demo to show the performance.I beg for the applications to test the 2D performance and the standard to show weather bad or good. Need your help~ There are a couple of benchmarking applications, we have nothing nouveau-specific though. The apps I know and use are : - gtkperf - render_bench - x11perf with the AA font test That's about it. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] xf86-video-nouveau does not compile
Oops replying to the list as well this time... Hi, Do you have the DRM compiled and installed ? Also, line 369 of nv_type.h is not about fifo for me (nor for git head), so are you sure you're using an unmodified git checkout ? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Oops with Nouveau on amd64 with nv15 card and kernel 2.6.22 (debian sid)
On 10/28/07, Daniel van Eeden [EMAIL PROTECTED] wrote: Stephane, Thanks for the quick response. I've tried today's git and the Oops went away. drm and nouveau are working. :) I tried mesa, but that failed with the following error (backtrace is attached) It's expected. We're going to do a proper 3D driver soon, anyway ATM you would only be able to run glxgears on it... Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Oops with Nouveau on amd64 with nv15 card and kernel 2.6.22 (debian sid)
On 10/27/07, Daniel van Eeden [EMAIL PROTECTED] wrote: Hello, I've build drm and nouveau from git and got this error while starting Xorg. Another thing is that before the install instructions on the wiki worked I had to install xorg-dev. This was the error I got before installing xorg-dev: ./configure: line 20257: syntax error near unexpected token `RANDR,' ./configure: line 20257: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)' I'm not on the list so please keep me on CC. Can you please retry with current drm git ? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] G72 doesn't need ExaCopy workaround
On 10/20/07, Maarten Maathuis [EMAIL PROTECTED] wrote: It's entirely possible that your card does not have the bug. Yeah, we don't know precisely under what circumstances it's triggered. It seems to be related to texture data caching somehow, but that's all we know. Maybe i can figure out what the original card was with this issue. Anyone else have an opinion on how to deal with this? (remove the single entry, or try to narrow it down even further, etc) We could try to use the 3D engine to do copies on nv40, provided there's no issue with texture caching when doing copies to/from the same surface. Of course, the best solution is to look at how nvidia implement this. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] geforce 4 mx + 2.6.22 problem
On 10/10/07, Pietro Capriata [EMAIL PROTECTED] wrote: I have update my source with git , but i have also problem .. i post my X log and Kern log Thank you very much to help me ! Hello, These logs (at least the DRM part) seem like they have been generated with the older version of the DRM. The current version doesn't output messages in the same format. That probably means your DRM module is not properly updated/compiled/installed. Stephane PS: Could you please put those logs online and paste a url instead of attaching them ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] geforce 4 mx + 2.6.22 problem
Hi, I just pushed fixes to both DDX DRM. Could you please update/recompile both and retry ? Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] XRandR 180
On 10/8/07, Justin Dugger [EMAIL PROTECTED] wrote: Hi, Does the current tree implement Rotate 180? I can see 0, 90 and 270, but not 180. This feature might sound silly at first glance, but it happens to be highly useful for my convertible tablet laptop. I've browsed the current nv code and nouveau implementations, and it's pretty clear that the older xrandr implementation did not do this. Is there some secret in xrandr1.2 that I'm not seeing, or is the function also lacking in the current tree? This change seems like a fairly simple 20-ish line of code patch to support an additional rotation mode, but there's one thing I'm not clear on: does pNV map to some register in hardware, or is it simply a global state for the driver itself? Hello Our plan is a bit longer term than that. We want to implement hw accelerated rotate support through randr + EXA. On the minus side, it's not a 10-line job and requires us finishing up EXA composite() hookrs properly, but on the plus side, it'll be hw accelerated. Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] geforce 4 mx + 2.6.22 problem
On 10/8/07, Pietro Capriata [EMAIL PROTECTED] wrote: Hello i have an Imac g4 flat panel 1ghz with geforce 4mx , ubuntu gutsy and a 2.6.22 kernel . I have tried nouveau, but i have some problem. I post also my log ... thx Hi, We also need to see the matching kernel log... Thanks, Stephane ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] geforce 4 mx + 2.6.22 problem
On 10/8/07, Pietro Capriata [EMAIL PROTECTED] wrote: this and put dMA queque hang: dmaPut=C4, current=c8 , status c0 thx for all (and excuse for my weird pc) What does it say with that patch ? Stephane diff Description: Binary data ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
