[Bug 12176] 1D depth texture with GL_LUMINANCE mode is incorrect
http://bugs.freedesktop.org/show_bug.cgi?id=12176 Zou Nan hai [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Zou Nan hai [EMAIL PROTECTED] 2008-03-25 23:07:27 PST --- Fixed in mesa -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - 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
[Bug 6790] VIA Unichrome / Pro prolems
http://bugzilla.kernel.org/show_bug.cgi?id=6790 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #13 from [EMAIL PROTECTED] 2008-03-25 23:25 --- This appears to be IRQ assignment problem. CCing to Len, take a look. Maybe this needs to be re-assigned to ACPI? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 13391] [945GM] Intermittent Xorg crashes with compiz
http://bugs.freedesktop.org/show_bug.cgi?id=13391 --- Comment #7 from Zou Nan hai [EMAIL PROTECTED] 2008-03-25 23:26:29 PST --- Hi Ben, We have fixed quite some bugs in mesa those days, Could you check if the crash on the latest mesa master branch? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - 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
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #2 from Oliver McFadden [EMAIL PROTECTED] 2008-03-26 04:51:08 PST --- I just tested this on my development box (r300-vertprog-branch, ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)) and I can reproduce the lockup. The first time executed fine, but the second time hard locked. I looked at your debug log and it looks like it dies somewhere during processing of an indirect buffer, then just sits in a loop waiting for the CP to idle. Probably that indirect buffer does something it shouldn't... Mar 25 15:16:53 debian kernel: [drm:drm_unlocked_ioctl] pid=3090, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 Mar 25 15:16:53 debian kernel: [drm:radeon_cp_indirect] idx=11 s=0 e=112 d=0 Mar 25 15:16:53 debian kernel: [drm:radeon_cp_dispatch_indirect] buf=11 s=0x0 e=0x70 Mar 25 15:16:53 debian kernel: [drm:drm_unlocked_ioctl] pid=3090, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 Mar 25 15:16:53 debian kernel: [drm:radeon_cp_idle] Mar 25 15:16:53 debian kernel: [drm:radeon_do_cp_idle] Mar 25 15:16:53 debian kernel: [drm:drm_unlocked_ioctl] ret = -16 Mar 25 15:16:53 debian kernel: [drm:drm_unlocked_ioctl] pid=3090, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 ... Defining RADEON_FIFO_DEBUG to 1 at the top of radeon_cp.c will give some more information, though not a lot; still useful though. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - 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
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #3 from Markus Amsler [EMAIL PROTECTED] 2008-03-26 06:17:14 PST --- Created an attachment (id=15472) -- (http://bugs.freedesktop.org/attachment.cgi?id=15472) drm log with RADEON_FIFO_DEBUG -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - 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: DRM QWS
On Wednesday 19 March 2008 16:26:37 Zack Rusin wrote: On Wednesday 19 March 2008 05:21:43 am Tom Cooksey wrote: 2) Sortof related to the above... it would be very cool to have a very simple drawing API to use on top of the modesetting API. A simple blit solid fill would surfice. I've always found it odd that the internal kernal API for framebuffer devices includes blit and solid fill, but that API is never exposed to user-space applications - even though it would be _very_ useful. I don't think this will be done. Main reason is that newer hw is hard to program, no 2d anymore so you have to program the whole 3d pipeline stuff and we don't want such code in kernel. So the idea here is to use one userspace driver like gallium3d. Basicly you do a winsys for your use and you can also do a new frontend for gallium other than a GL frontend or wait for new frontend to appear :) Hmm... If you have to use gallium to talk to the hardware, shouldn't fbcon be renamed to glcon? :-) Also, while 2D is dissappearing on desktop, it's very much alive on embedded, for the moment at least. That depends on your definition of embedded. I think what you're referring to are dummy framebuffers or gpu's that were made with some absolutely silly requirements like no known bugs policy which implies that all they have is an underperforming 2D engine. In both of those cases you already lost. So if you're trying to accelerate or design framework based on those than honestly you can just give up and go with an all software framework. If you're referring to actual embedded GPU's the current generation is actually already fully programmable and if you're designing with those in mind than what Jerome said holds. I was initially thinking about low-end graphics hardware, which are mainly just dummy framebuffers as you say. However, I've thought some more about this and there's still set-top-box type hardware here, which need to decode full resolution HD video (1920×1080 or even 3840×2160). Typically this is off-loaded onto a dedicated DSP. E.g. TI's DaVinci platform manages to do Full-HD resolution h.264 decoding in a ~2W power envolope. I believe the video is composited with a normal framebuffer (for the UI) in hardware. I don't think there's any programmable 3D hardware avaliable which can do 1920×1080 resolutions in a 2W power envelope. So even if they replace the linear framebuffer with a programmable 3D core, that core still needs to render at [EMAIL PROTECTED] fps without impacting the 2W power draw too much. I guess it will probably be possible in 5 years or so, but it's not possible now. I can't see fbdev going anytime soon if the only replacement is a full-blown programmable 3D driver architecture. Perhaps a new, simple API could be created. On desktop it would be implemented as a new front-end API for gallium and on embedded it would be implemented using a thin user-space wrapper to the kernel module? I don't think that makes a lot of sense. Gallium3D is an interface to hardware - it models the way modern graphics hardware works. Front-end's in the Gallium3D sense are the state-trackers that are used by the API that you're trying to accelerate. So if your hardware is an actual GPU that you can write a Gallium3D driver for, than front-end for it would be just another api (you could be just using GL at this point). I guess what I was thinking about was a single API which can be used on 3D-less (or legacy, if you want) hardware and on modern hardware. If the graphics hardware is a simple pointer to a main-memory buffer which is scanned out to the display, then your right, you might as well just use user-space shared memory, as we currently do. A new API would only be useful for devices with video memory and a hardware blitter. There are still new devices coming out with this kind of hardware, the Marvel PXA3x0 and Freescale i.MX27 for example spring to mind. I'm still a bit confused about what's meant to be displayed during the boot process, before the root fs is mounted. Will the gallium libraries drivers need to be in the initramfs? If not, what shows the splash screen provides single-user access if anything goes wrong in the boot process? A bit like what DirectFB started life as (before it started trying to be X). Well, that's what you end up with when you start adding things that you need across devices. I know that in the beginning when you look at the stack you tend to think this could be a lot smaller!, but then with time you realize that you actually need all of those things but instead of optimizing the parts that were there you went some custom solution and are now stuck with it. I was refering here to DirectFB's window management, input device abstraction, audio interface abstraction video streaming APIs. Personally, I believe there is a requirement for a simple,
Re: DRM QWS
On Wed, Mar 26, 2008 at 1:50 PM, Tom Cooksey [EMAIL PROTECTED] wrote: ... I guess what I was thinking about was a single API which can be used on 3D-less (or legacy, if you want) hardware and on modern hardware. If the graphics hardware is a simple pointer to a main-memory buffer which is scanned out to the display, then your right, you might as well just use user-space shared memory, as we currently do. A new API would only be useful for devices with video memory and a hardware blitter. There are still new devices coming out with this kind of hardware, the Marvel PXA3x0 and Freescale i.MX27 for example spring to mind. I agree with you that it probably doesn't make sense to use gallium/mesa on everything everywhere. There are still small devices or early boot scenarios (you mention initramfs) where gallium isn't appropriate. However, there is no need to put this a 2D engine into the kernel. What the drm ttm gives us is a nice abstraction for memory management and command buffer submission, and drm modesetting builds on this to let the kernel set a graphics mode. And that's all that we need in the kernel. Building a small userspace library on top of this to accelerate blits and fills should be pretty easy. cheers, Kristian - 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
[Bug 6790] VIA Unichrome / Pro prolems
http://bugzilla.kernel.org/show_bug.cgi?id=6790 --- Comment #14 from [EMAIL PROTECTED] 2008-03-26 15:35 --- Workaround: Using the openChrome X11 driver does not tirgger this bug ( http://www.openchrome.org/ ). See also http://lkml.org/lkml/2008/3/16/10 for a bit detailed description. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 6790] VIA Unichrome / Pro prolems
http://bugzilla.kernel.org/show_bug.cgi?id=6790 --- Comment #15 from [EMAIL PROTECTED] 2008-03-26 15:39 --- Great information, thanks. Will this also apply in the bug mentioned in #12? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #4 from Markus Amsler [EMAIL PROTECTED] 2008-03-26 17:37:02 PST --- Created an attachment (id=15493) -- (http://bugs.freedesktop.org/attachment.cgi?id=15493) mesa patch This patch makes the lockup gone. I have absolutely no clue why. I just knew RADEON_DEBUG=sync fixes the lockup. So I peppered the source with radeonWaitForIdle until I found this hack -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - 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
[Bug 15193] mesa xdemo 'glthreads' draw nothing
http://bugs.freedesktop.org/show_bug.cgi?id=15193 --- Comment #5 from Colin.Joe [EMAIL PROTECTED] 2008-03-26 18:33:17 PST --- I have rolled back and retested it , this bug still can be reproduced . -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - 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
[Bug 11099] [945] FlightGears's joy stick displays abnormal
http://bugs.freedesktop.org/show_bug.cgi?id=11099 Gordon Jin [EMAIL PROTECTED] changed: What|Removed |Added CC||dri- ||[EMAIL PROTECTED] AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Summary|FlightGears's joy stick |[945] FlightGears's joy |displays abnormal |stick displays abnormal -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug. - 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
[Bug 15193] mesa xdemo 'glthreads' draw nothing
http://bugs.freedesktop.org/show_bug.cgi?id=15193 --- Comment #6 from Zou Nan hai [EMAIL PROTECTED] 2008-03-26 22:54:36 PST --- It seems threads has some synchoronize issue with xcb. Can you try build the X server without xcb to see if the issue still exist? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - 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
