Re: Wavering Arrandale output
On Fri, 13 May 2011 17:45:11 -0300, "Gustavo F. Padovan" wrote: > Hi Chris, > > Bug #28306 is going to complete his first birthday at the end of this month, > it is nagging around for a long time and I have many interest in fix this. > > So I tested your patch in duplicated bug #36599 and it doesn't work, but I > managed to add some printks(see diff) there to help debug. > > [1.033866] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > [1.033868] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > [1.033869] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 1 > [1.034120] [drm:intel_crtc_mode_set] *ERROR* is_lvds 1 > [1.034121] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > (null) > [1.191465] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > [1.191466] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > [1.191468] [drm:intel_crtc_mode_set] *ERROR* encoder->type 1 > [1.191469] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 0 > [1.191720] [drm:intel_crtc_mode_set] *ERROR* is_lvds 0 > [1.191721] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > (null) > > It seems your patch has no effect once has_edp_encoder is null. Can you please > look into this? I can provide any test you may want, just send me the patches. > ;) With no eDP on the system, we wouldn't expect to apply any of the eDP settings. Even after your fix to the patch, nothing? Can you try just setting use_ssc=0 (and keep your fix). In 633f2ea26665d37bb3c8ae30799aa14988622653 (drm/i915: Disable SSC for outputs other than LVDS or DP) I tried to implement another aspect of source-clock control, that is the patch that appeared to work if you only had VGA connected. So the next step would be to combine the two patches. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37193] New: Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 Summary: Crash while switching between OpenGL window and other window Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: i...@noctus.net Thanks to the Unigine Heaven demo I was finally able to reliably reproduce an issue which I only experienced with Mplayer before. Upon switching back and forth between one window where OpenGL is used and another one, quickly the whole input and output of X freezes followed by a hard restart of my system a few moments later. Conditions to reproduce here: 1) Have the Composite extension enabled - the crash does not occur without the Composite extension - disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the crashes 2) Have rencer acceleration enabled - Setting RenderAccel to "Off" prevents the crashes - Crashes occur both with EXA as well as XAA 3) Start an application which opens an OpenGL context with a least amount of complexity wrt the graphics - Crash is reproducible with Mplayer using the GL video output - Also reproducible with the Unigine Heaven demo - Not reproducible with glxgears (seemingly too simple) 4) Open another application window and start switching back and forth between those two Due to the hard restart I am currently unable to find any traces of debugging information so help for getting started on this is greatly appreciated. I am aware that there are quite a few other reports which sound similar to this one and I thought about adding a comment on these. However, without any additional info to add, my comment wouldn’t be that much worth. Thus I am mostly hoping for help on gathering as much information as possible. Aside from using the latest Mesa git master I am also using the latest git master of the xf86-video-ati DDX. (I also wanted to spare you from this lengthy message in #dri-devel ;-) ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote: > Em 18-04-2011 17:15, Jesse Barker escreveu: > > One of the big issues we've been faced with at Linaro is around GPU > > and multimedia device integration, in particular the memory management > > requirements for supporting them on ARM. This next cycle, we'll be > > focusing on driving consensus around a unified memory management > > solution for embedded systems that support multiple architectures and > > SoCs. This is listed as part of our working set of requirements for > > the next six-month cycle (in spite of the URL, this is not being > > treated as a graphics-specific topic - we also have participation from > > multimedia and kernel working group folks): > > > > https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics > > As part of the memory management needs, Linaro organized several discussions > during Linaro Development Summit (LDS), at Budapest, and invited me and other > members of the V4L and DRI community to discuss about the requirements. > I wish to thank Linaro for its initiative. > > Basically, on several SoC designs, the GPU and the CPU are integrated into > the same chipset and they can share the same memory for a framebuffer. Also, > they may have some IP blocks that allow processing the framebuffer internally, > to do things like enhancing the image and converting it into an mpeg stream. > > The desire, from the SoC developers, is that those operations should be > done using zero-copy transfers. > > This resembles somewhat the idea of the VIDIOC_OVERLAY/VIDIOC_FBUF API, > that was used in the old days where CPUs weren't fast enough to process > video without generating a huge load on it. So the overlay mode were created > to allow direct PCI2PCI transfers from the video capture board into the > display adapter, using XVideo extension, and removing the overload at the > CPU due to a video stream. It were designed as a Kernel API for it, and an > userspace X11 driver, that passes a framebuffer reference to the V4L driver, > where it is used to program the DMA transfers to happen inside the > framebuffer. > > At the LDS, we had a 3-day discussions about how the buffer sharing should > be handled, and Linaro is producing a blueprint plan to address the needs. > We had also a discussion about V4L and KMS, allowing both communities to > better > understand how things are supposed to work on the other side. > > From V4L2 perspective, what is needed is to create a way to somehow allow > passing a framebuffer between two V4L2 devices and between a V4L2 device > and GPU. The V4L2 device can either be an input or an output one. > The original idea were to add yet-another-mmap-mode at the VIDIOC streaming > ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed > there, this would leed into sync issues on a shared buffer, causing flip > effects. Also, as the API is generic, it can be used also on generic > computers, > like desktops, notebooks and tablets (even on arm-based designs), and it > may end to be actually implemented as a PCI2PCI transfer. > > So, based at all I've seen, I'm pretty much convinced that the normal MMAP > way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) > are not the best way to share data with framebuffers. I agree with that, but it is a different story between two V4L2 devices. There you obviously want to use the streaming ioctls and still share buffers. > We probably need > something that it will be an enhanced version of the > VIDIOC_FBUF/VIDIOC_OVERLAY > ioctls. Unfortunately, we can't just add more stuff there, as there's no > reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. That will be useful as well to add better support for blending and Z-ordering between overlays. The old API for that is very limited in that respect. Regards, Hans > It seems to me that the proper way to develop such API is to start working > with Xorg V4L driver, changing it to work with KMS and with the new API > (probably porting some parts of the Xorg driver to kernelspace). > > One of the problems with a shared framebuffer is that an overlayed V4L stream > may, at the worse case, be sent to up to 4 different GPU's and/or displays. > > Imagine a scenario like: > > ===+=== > | | | > | D1 +|---+ D2 | > | | V4L| | | > +-|+---|--| > | || | | > | D3 ++---+ D4 | > | | | > === > > > Where D1, D2, D3 and D4 are 4 different displays, and the same V4L > framebuffer is > partially shared between them (the above is an example of a V4L input, > although > the reverse scenario of having one frame buffer divided into
[Bug 37193] Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 --- Comment #1 from Mathias Brodala 2011-05-14 04:56:39 PDT --- (In reply to comment #0) >- disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the > crashes This should actually read "does not prevent". -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)
https://bugs.freedesktop.org/show_bug.cgi?id=35502 Chris Sherlock changed: What|Removed |Added CC||ta.bu.shi.da...@gmail.com --- Comment #12 from Chris Sherlock 2011-05-14 05:32:09 PDT --- *** Bug 32662 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 18-04-2011 17:15, Jesse Barker escreveu: > One of the big issues we've been faced with at Linaro is around GPU > and multimedia device integration, in particular the memory management > requirements for supporting them on ARM. This next cycle, we'll be > focusing on driving consensus around a unified memory management > solution for embedded systems that support multiple architectures and > SoCs. This is listed as part of our working set of requirements for > the next six-month cycle (in spite of the URL, this is not being > treated as a graphics-specific topic - we also have participation from > multimedia and kernel working group folks): > > https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics As part of the memory management needs, Linaro organized several discussions during Linaro Development Summit (LDS), at Budapest, and invited me and other members of the V4L and DRI community to discuss about the requirements. I wish to thank Linaro for its initiative. Basically, on several SoC designs, the GPU and the CPU are integrated into the same chipset and they can share the same memory for a framebuffer. Also, they may have some IP blocks that allow processing the framebuffer internally, to do things like enhancing the image and converting it into an mpeg stream. The desire, from the SoC developers, is that those operations should be done using zero-copy transfers. This resembles somewhat the idea of the VIDIOC_OVERLAY/VIDIOC_FBUF API, that was used in the old days where CPUs weren't fast enough to process video without generating a huge load on it. So the overlay mode were created to allow direct PCI2PCI transfers from the video capture board into the display adapter, using XVideo extension, and removing the overload at the CPU due to a video stream. It were designed as a Kernel API for it, and an userspace X11 driver, that passes a framebuffer reference to the V4L driver, where it is used to program the DMA transfers to happen inside the framebuffer. At the LDS, we had a 3-day discussions about how the buffer sharing should be handled, and Linaro is producing a blueprint plan to address the needs. We had also a discussion about V4L and KMS, allowing both communities to better understand how things are supposed to work on the other side. >From V4L2 perspective, what is needed is to create a way to somehow allow passing a framebuffer between two V4L2 devices and between a V4L2 device and GPU. The V4L2 device can either be an input or an output one. The original idea were to add yet-another-mmap-mode at the VIDIOC streaming ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed there, this would leed into sync issues on a shared buffer, causing flip effects. Also, as the API is generic, it can be used also on generic computers, like desktops, notebooks and tablets (even on arm-based designs), and it may end to be actually implemented as a PCI2PCI transfer. So, based at all I've seen, I'm pretty much convinced that the normal MMAP way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) are not the best way to share data with framebuffers. We probably need something that it will be an enhanced version of the VIDIOC_FBUF/VIDIOC_OVERLAY ioctls. Unfortunately, we can't just add more stuff there, as there's no reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. It seems to me that the proper way to develop such API is to start working with Xorg V4L driver, changing it to work with KMS and with the new API (probably porting some parts of the Xorg driver to kernelspace). One of the problems with a shared framebuffer is that an overlayed V4L stream may, at the worse case, be sent to up to 4 different GPU's and/or displays. Imagine a scenario like: ===+=== | | | | D1 +|---+ D2 | | | V4L| | | +-|+---|--| | || | | | D3 ++---+ D4 | | | | === Where D1, D2, D3 and D4 are 4 different displays, and the same V4L framebuffer is partially shared between them (the above is an example of a V4L input, although the reverse scenario of having one frame buffer divided into 4 V4L outputs also seems to be possible). As the same image may be divided into 4 monitors, the buffer filling should be synced with all of them, in order to avoid flipping effects. Also, the shared buffer can't be re-used until all displays finish reading. From what I understood from the discussions with DRI people, the display API's currently has similar issues of needing to wait for a buffer to be completely used before allowing it to be re-used. According to them, this were solved there by dynamically allocating buffers. We may need t
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 14-05-2011 13:02, Hans Verkuil escreveu: > On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote: >> So, based at all I've seen, I'm pretty much convinced that the normal MMAP >> way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) >> are not the best way to share data with framebuffers. > > I agree with that, but it is a different story between two V4L2 devices. There > you obviously want to use the streaming ioctls and still share buffers. I don't think so. the requirement for syncing the framebuffer between the two V4L2 devices is pretty much the same as we have with one V4L2 device and one GPU. On both cases, the requirement is to pass a framebuffer between two entities, and not a video stream. For example, imagine something like: V4L2 camera => V4L2 encoder t MPEG2 || LL==> GPU Both GPU and the V4L2 encoder should use the same logic to be sure that they will use a buffer that were filled already by the camera. Also, the V4L2 camera driver can't re-use such framebuffer before being sure that both consumers has already stopped using it. So, it is the same requirement as having four displays receiving such framebuffer. Of course, a GPU endpoint may require some extra information for the blending, but also a V4L node may require some other type of extra information. >> We probably need >> something that it will be an enhanced version of the >> VIDIOC_FBUF/VIDIOC_OVERLAY >> ioctls. Unfortunately, we can't just add more stuff there, as there's no >> reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. > > That will be useful as well to add better support for blending and Z-ordering > between overlays. The old API for that is very limited in that respect. Agreed. Mauro. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #9 from Milan Plzik 2011-05-14 07:02:04 PDT --- Created an attachment (id=46709) View: https://bugs.freedesktop.org/attachment.cgi?id=46709 Review: https://bugs.freedesktop.org/review?bug=35998&attachment=46709 R300 texture alignment partial fix As Marek stated, this issue is related to texture alignment. After playing with mesa/src/gallium/drivers/r300/r300_texture_desc.c (see attached patch), I was able to get things rendering properly -- font issue disappeared with setting 'height' alignment of 8bpp textures to '2' and misrendered artifacts on some round edges with 32bpp textures and 'height' alignment to 2. Patch contains only values I needed to fix -- I guess there is some relation between parts of array I've been modifying. Unfortunately, this patch causes, that some (random) of GNOME 3's popup windows are being rendered improperly -- their content looks like portions of other textures (e.g. desktop background, icons, ...; random parts of vram), with no apparent relation to expected content. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37203] New: Tiny and Big: Menu is too bright
https://bugs.freedesktop.org/show_bug.cgi?id=37203 Summary: Tiny and Big: Menu is too bright Product: Mesa Version: git Platform: Other URL: http://www.tinyandbig.com/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se Created an attachment (id=46713) --> (https://bugs.freedesktop.org/attachment.cgi?id=46713) Screenshot of the bug The game Tiny and Big have a minor problem, after loading, the menu is too bright. This is probably not related to other too-bright bugs such as 37150 as r300g and llvmpipe renders the menu fine. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: ad2999d2113356d526b39774eb8114e974dac048 -- drm: 2.4.25 -- kernel: 2.6.39-rc7 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37203] Tiny and Big: Menu is too bright
https://bugs.freedesktop.org/show_bug.cgi?id=37203 --- Comment #1 from Sven Arvidsson 2011-05-14 08:09:13 PDT --- Created an attachment (id=46714) --> (https://bugs.freedesktop.org/attachment.cgi?id=46714) Correct rendering -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37193] Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 --- Comment #2 from Alex Deucher 2011-05-14 09:28:41 PDT --- Can you attach your xorg log and dmesg output? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #10 from Alex Deucher 2011-05-14 09:34:43 PDT --- RS600/RS690/RS740 require 64 bit texture pitch alignment, perhaps the tile alignment needs some adjustment as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #11 from Alex Deucher 2011-05-14 09:55:26 PDT --- *64 byte -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36268] [r300g, bisected] minor flickering in Unigine Sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=36268 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Olšák 2011-05-14 11:05:52 PDT --- Fixed by 51095f74cf92d3cada7366ce898ade7693570b48. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g
https://bugs.freedesktop.org/show_bug.cgi?id=36609 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Marek Olšák 2011-05-14 11:06:10 PDT --- Fixed by 51095f74cf92d3cada7366ce898ade7693570b48. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Wavering Arrandale output
* Chris Wilson [2011-05-14 08:55:15 +0100]: > On Fri, 13 May 2011 17:45:11 -0300, "Gustavo F. Padovan" > wrote: > > Hi Chris, > > > > Bug #28306 is going to complete his first birthday at the end of this month, > > it is nagging around for a long time and I have many interest in fix this. > > > > So I tested your patch in duplicated bug #36599 and it doesn't work, but I > > managed to add some printks(see diff) there to help debug. > > > > [1.033866] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > > [1.033868] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > > [1.033869] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 1 > > [1.034120] [drm:intel_crtc_mode_set] *ERROR* is_lvds 1 > > [1.034121] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > > (null) > > [1.191465] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > > [1.191466] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > > [1.191468] [drm:intel_crtc_mode_set] *ERROR* encoder->type 1 > > [1.191469] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 0 > > [1.191720] [drm:intel_crtc_mode_set] *ERROR* is_lvds 0 > > [1.191721] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > > (null) > > > > It seems your patch has no effect once has_edp_encoder is null. Can you > > please > > look into this? I can provide any test you may want, just send me the > > patches. > > ;) > > With no eDP on the system, we wouldn't expect to apply any of the eDP > settings. > > Even after your fix to the patch, nothing? Can you try just setting > use_ssc=0 (and keep your fix). Nothing. -- Gustavo F. Padovan http://profusion.mobi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #12 from Milan Plzik 2011-05-14 14:04:05 PDT --- I'm sorry, I was talking about tile alignment whole time, the modified function was r300_get_pixel_alignment, which definitely returns "tile" . Sorry for confusion. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34252] Unexpected behaviour when switching video cards with vga_switcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=34252 Rafael J. Wysocki changed: What|Removed |Added Status|NEW |RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #12 from Rafael J. Wysocki 2011-05-14 22:19:01 --- Patch : https://bugzilla.kernel.org/attachment.cgi?id=57582 Handled-By : Florian Mickler -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 Rafael J. Wysocki changed: What|Removed |Added Status|NEW |NEEDINFO -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc7-git7: Reported regressions from 2.6.38
This message contains a list of some regressions from 2.6.38, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.38, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2011-05-15 50 12 11 2011-04-30 38 17 16 2011-04-17 17 11 10 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35062 Subject : Suspend to ram stopped working after commit of " intel-iommu: Unlink domain from iommu " Submitter : Date: 2011-05-14 11:08 (1 days old) First-Bad-Commit: http://git.kernel.org/linus/a97590e56d0d58e1dd262353f7cbd84e81d8e600 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34952 Subject : 2.6.39-rc6: SATA hangs for a few seconds during boot Submitter : Tino Keitel Date: 2011-05-09 20:48 (6 days old) Message-ID : <20110509204801.ga2...@x61.home> References : http://marc.info/?l=linux-kernel&m=130497409509438&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34942 Subject : [Bug] Kdump does not work when panic triggered due to MCE Submitter : K.Prasad Date: 2011-05-06 16:54 (9 days old) Message-ID : <20110506165412.gb2...@in.ibm.com> References : http://marc.info/?l=linux-kernel&m=130470087226270&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34662 Subject : Warning at block/genhd.c:1556 disk_clear_events Submitter : Meelis Roos Date: 2011-05-02 9:59 (13 days old) Message-ID : References : http://marc.info/?l=linux-kernel&m=130433037002610&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34492 Subject : [2.6.39-rc4, x86_32] Stall at default_idle() Submitter : Tetsuo Handa Date: 2011-04-27 4:49 (18 days old) Message-ID : <201104270449.p3r4n54n023...@www262.sakura.ne.jp> References : http://marc.info/?l=linux-kernel&m=130387977425687&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34202 Subject : MCEUSB remotes don't work with USB 3.0 ports Submitter : Aaron Barany Date: 2011-05-01 23:48 (14 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34002 Subject : [REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window Submitter : Maciej Rutecki Date: 2011-04-17 16:04 (28 days old) Message-ID : <201104171804.04664.maciej.rute...@gmail.com> References : http://marc.info/?l=linux-fbdev&m=130305625114863&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33842 Subject : NULL pointer dereference in ip_fragment Submitter : Tomas Carnecky Date: 2011-04-23 07:51 (22 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33792 Subject : lockdep trace when unplugging usb audio (.39rc4) Submitter : Dave Jones Date: 2011-04-19 18:07 (26 days old) Message-ID : <20110419180745.ga...@redhat.com> References : http://marc.info/?l=linux-kernel&m=130323648920431&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33272 Subject : drm related hard-hang Submitter : Peter Teoh Date: 2011-04-14 01:29 (31 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33242 Subject : Lockdep splat in autofs with 2.6.39-rc2 Submitter : Nick Bowler Date: 2011-04-07 19:44 (38 days old) Message-ID : <20110407194403.ga29...@elliptictech.com> References : http://marc.info/?l=linux-kernel&m=130220545614682&w=2 Regressions with patches Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33802 Subject : list_del corruption in sd driver since 2.6.39-rc4 Submitter : Christian Casteyde Date: 2011-04-21 21:10 (24 days old) Handled-By : James Bottomley Patch : http://marc.info/?l=linux-kernel&m=130271409412095 For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions from 2.6.38, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=32012 Please let the tracking team know if there are any Bugzilla entries that should be added to the list i
2.6.39-rc7-git7: Reported regressions 2.6.37 -> 2.6.38
[NOTE: This most likely is the last summary report of post-2.6.37 regressions introduced during the 2.6.38 development cycle. Please let us know what the current status of those bugs is, if possible, and thanks for all of the reports, updates and fixes.] This message contains a list of some post-2.6.37 regressions introduced before 2.6.38, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved post-2.6.37 regressions, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2011-05-15 107 23 20 2011-04-30 105 29 28 2011-04-17 98 28 28 2011-03-27 88 26 26 2011-03-06 70 27 26 2011-02-21 51 18 17 2011-02-12 39 20 18 2011-02-03 19 11 7 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34992 Subject : Regression with ath5k, cannot find any wireless network Submitter : Joshua Covington Date: 2011-05-12 11:24 (3 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33982 Subject : ath9k: regulatory: strange tx power limits Submitter : Richard Schütz Date: 2011-04-26 18:37 (19 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33882 Subject : rt2800pci bad performance in 2.6.38 Submitter : Ricardo Graça Date: 2011-04-23 14:35 (22 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33852 Subject : Regression of AR2413 802.11bg in 2.6.38.4 Submitter : Boris Popov Date: 2011-04-23 12:12 (22 days old) First-Bad-Commit: http://git.kernel.org/linus/42c025f3de9042d9c9abd9a6f6205d1a0f4bcadf Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33662 Subject : System hangs during X startup (kwin compositing?) Submitter : Luke-Jr Date: 2011-04-19 04:26 (26 days old) First-Bad-Commit: http://git.kernel.org/linus/e8616b6ced6137085e6657cc63bc2fe3900b8616 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32862 Subject : acer_wmi partially crashes ACPI/EC (Aspire 8930G) Submitter : Hector Martin Date: 2011-04-07 17:44 (38 days old) Handled-By : Lee, Chun-Yi Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32522 Subject : drm:i915_hangcheck_ring_idle after suspend/resume cycle Submitter : Date: 2011-04-02 18:40 (43 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32202 Subject : 2.6.38 hangs on boot until key is pressed Submitter : Tvrtko Ursulin Date: 2011-03-27 19:18 (49 days old) Message-ID : <1301253485.2500.2.camel@deuteros> References : http://marc.info/?l=linux-kernel&m=13012546558&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31922 Subject : ath5k: Decreased throughput in IBSS or 802.11n mode Submitter : Jeff Cook Date: 2011-03-26 20:06 (50 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31782 Subject : nouveau: lockdep spew Submitter : Johannes Berg Date: 2011-03-24 09:51 (52 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31572 Subject : BUG in vb_alloc() - firewire crash at boot Submitter : Pavel Kysilka Date: 2011-03-21 12:40 (55 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31402 Subject : Diminished brightness at startup Submitter : Guilherme Salazar Date: 2011-03-18 16:29 (58 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31322 Subject : 2.6.38-rc echo 3 > /proc/sys/vm/drop_caches repairs mplayer distortions Submitter : Hans de Bruin Date: 2011-03-14 21:34 (62 days old) Message-ID : <4d7e89e7.3080...@xmsnet.nl> References : http://marc.info/?l=linux-kernel&m=130014181919827&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31012 Subject : WARNING: Perf: bad frame pointer = (null), 2.6.38-rc8 Submitter : Chuck Ebbert Date: 2011-03-12 19:08 (64 days old) Message-ID : <20110312140851.52420149@katamari> References : http://marc.info/?l=linux-kernel&m=129995721014931&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30992 Subject
[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium
https://bugs.freedesktop.org/show_bug.cgi?id=36952 --- Comment #10 from dri tester 2011-05-14 17:55:51 PDT --- (In reply to comment #9) > Created an attachment (id=46696) View: https://bugs.freedesktop.org/attachment.cgi?id=46696 Review: https://bugs.freedesktop.org/review?bug=36952&attachment=46696 > possible fix > > Could you try this patch? The patch applied to latest mesa-git allows crackberg to run at the expected framerate with the expected cpu% for a few seconds (5-15 seconds), then it segfaults. The segfault might be caused by a different commit. Would it be worth bisecting again but applying the possible fix patch above each time before compiling to see if I can find another bad commit? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium
https://bugs.freedesktop.org/show_bug.cgi?id=36952 --- Comment #11 from Marek Olšák 2011-05-14 18:08:28 PDT --- It would be better to experiment with the patch and try smaller buffer sizes. Please let me know when you find a size which works. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35095] [r300g] HiZ broken in WoW
https://bugs.freedesktop.org/show_bug.cgi?id=35095 --- Comment #9 from Marek Olšák 2011-05-14 18:40:57 PDT --- Could you test the latest Mesa master branch? There are some new HiZ fixes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4
https://bugs.freedesktop.org/show_bug.cgi?id=36745 --- Comment #15 from Marek Olšák 2011-05-14 19:07:14 PDT --- Andrew, could you please make an OpenGL trace file using apitrace? Get it here: https://github.com/apitrace/apitrace Compile it using cmake, then run something like: TRACE_FILE=/home/..user../3dmark.trace LD_PRELOAD=/path-to-apitrace/glxtrace.so ./executable where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me. That will capture all the 3D commands and I can replay it here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 Johannes Berg changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||CODE_FIX --- Comment #10 from Johannes Berg 2011-05-15 06:24:28 --- Sorry, I must've missed your email earlier -- I'm now on 2.6.39-rc7 and it doesn't seem to have this issue any more. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Wavering Arrandale output
On Fri, 13 May 2011 17:45:11 -0300, "Gustavo F. Padovan" wrote: > Hi Chris, > > Bug #28306 is going to complete his first birthday at the end of this month, > it is nagging around for a long time and I have many interest in fix this. > > So I tested your patch in duplicated bug #36599 and it doesn't work, but I > managed to add some printks(see diff) there to help debug. > > [1.033866] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > [1.033868] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > [1.033869] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 1 > [1.034120] [drm:intel_crtc_mode_set] *ERROR* is_lvds 1 > [1.034121] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > (null) > [1.191465] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > [1.191466] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > [1.191468] [drm:intel_crtc_mode_set] *ERROR* encoder->type 1 > [1.191469] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 0 > [1.191720] [drm:intel_crtc_mode_set] *ERROR* is_lvds 0 > [1.191721] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > (null) > > It seems your patch has no effect once has_edp_encoder is null. Can you please > look into this? I can provide any test you may want, just send me the patches. > ;) With no eDP on the system, we wouldn't expect to apply any of the eDP settings. Even after your fix to the patch, nothing? Can you try just setting use_ssc=0 (and keep your fix). In 633f2ea26665d37bb3c8ae30799aa14988622653 (drm/i915: Disable SSC for outputs other than LVDS or DP) I tried to implement another aspect of source-clock control, that is the patch that appeared to work if you only had VGA connected. So the next step would be to combine the two patches. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 37193] New: Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 Summary: Crash while switching between OpenGL window and other window Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: info at noctus.net Thanks to the Unigine Heaven demo I was finally able to reliably reproduce an issue which I only experienced with Mplayer before. Upon switching back and forth between one window where OpenGL is used and another one, quickly the whole input and output of X freezes followed by a hard restart of my system a few moments later. Conditions to reproduce here: 1) Have the Composite extension enabled - the crash does not occur without the Composite extension - disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the crashes 2) Have rencer acceleration enabled - Setting RenderAccel to "Off" prevents the crashes - Crashes occur both with EXA as well as XAA 3) Start an application which opens an OpenGL context with a least amount of complexity wrt the graphics - Crash is reproducible with Mplayer using the GL video output - Also reproducible with the Unigine Heaven demo - Not reproducible with glxgears (seemingly too simple) 4) Open another application window and start switching back and forth between those two Due to the hard restart I am currently unable to find any traces of debugging information so help for getting started on this is greatly appreciated. I am aware that there are quite a few other reports which sound similar to this one and I thought about adding a comment on these. However, without any additional info to add, my comment wouldn?t be that much worth. Thus I am mostly hoping for help on gathering as much information as possible. Aside from using the latest Mesa git master I am also using the latest git master of the xf86-video-ati DDX. (I also wanted to spare you from this lengthy message in #dri-devel ;-) ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote: > Em 18-04-2011 17:15, Jesse Barker escreveu: > > One of the big issues we've been faced with at Linaro is around GPU > > and multimedia device integration, in particular the memory management > > requirements for supporting them on ARM. This next cycle, we'll be > > focusing on driving consensus around a unified memory management > > solution for embedded systems that support multiple architectures and > > SoCs. This is listed as part of our working set of requirements for > > the next six-month cycle (in spite of the URL, this is not being > > treated as a graphics-specific topic - we also have participation from > > multimedia and kernel working group folks): > > > > https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics > > As part of the memory management needs, Linaro organized several discussions > during Linaro Development Summit (LDS), at Budapest, and invited me and other > members of the V4L and DRI community to discuss about the requirements. > I wish to thank Linaro for its initiative. > > Basically, on several SoC designs, the GPU and the CPU are integrated into > the same chipset and they can share the same memory for a framebuffer. Also, > they may have some IP blocks that allow processing the framebuffer internally, > to do things like enhancing the image and converting it into an mpeg stream. > > The desire, from the SoC developers, is that those operations should be > done using zero-copy transfers. > > This resembles somewhat the idea of the VIDIOC_OVERLAY/VIDIOC_FBUF API, > that was used in the old days where CPUs weren't fast enough to process > video without generating a huge load on it. So the overlay mode were created > to allow direct PCI2PCI transfers from the video capture board into the > display adapter, using XVideo extension, and removing the overload at the > CPU due to a video stream. It were designed as a Kernel API for it, and an > userspace X11 driver, that passes a framebuffer reference to the V4L driver, > where it is used to program the DMA transfers to happen inside the > framebuffer. > > At the LDS, we had a 3-day discussions about how the buffer sharing should > be handled, and Linaro is producing a blueprint plan to address the needs. > We had also a discussion about V4L and KMS, allowing both communities to > better > understand how things are supposed to work on the other side. > > From V4L2 perspective, what is needed is to create a way to somehow allow > passing a framebuffer between two V4L2 devices and between a V4L2 device > and GPU. The V4L2 device can either be an input or an output one. > The original idea were to add yet-another-mmap-mode at the VIDIOC streaming > ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed > there, this would leed into sync issues on a shared buffer, causing flip > effects. Also, as the API is generic, it can be used also on generic > computers, > like desktops, notebooks and tablets (even on arm-based designs), and it > may end to be actually implemented as a PCI2PCI transfer. > > So, based at all I've seen, I'm pretty much convinced that the normal MMAP > way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) > are not the best way to share data with framebuffers. I agree with that, but it is a different story between two V4L2 devices. There you obviously want to use the streaming ioctls and still share buffers. > We probably need > something that it will be an enhanced version of the > VIDIOC_FBUF/VIDIOC_OVERLAY > ioctls. Unfortunately, we can't just add more stuff there, as there's no > reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. That will be useful as well to add better support for blending and Z-ordering between overlays. The old API for that is very limited in that respect. Regards, Hans > It seems to me that the proper way to develop such API is to start working > with Xorg V4L driver, changing it to work with KMS and with the new API > (probably porting some parts of the Xorg driver to kernelspace). > > One of the problems with a shared framebuffer is that an overlayed V4L stream > may, at the worse case, be sent to up to 4 different GPU's and/or displays. > > Imagine a scenario like: > > ===+=== > | | | > | D1 +|---+ D2 | > | | V4L| | | > +-|+---|--| > | || | | > | D3 ++---+ D4 | > | | | > === > > > Where D1, D2, D3 and D4 are 4 different displays, and the same V4L > framebuffer is > partially shared between them (the above is an example of a V4L input, > although > the reverse scenario of having one frame buffer divided into
[Bug 37193] Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 --- Comment #1 from Mathias Brodala 2011-05-14 04:56:39 PDT --- (In reply to comment #0) >- disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the > crashes This should actually read "does not prevent". -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)
https://bugs.freedesktop.org/show_bug.cgi?id=35502 Chris Sherlock changed: What|Removed |Added CC||ta.bu.shi.da.yu at gmail.com --- Comment #12 from Chris Sherlock 2011-05-14 05:32:09 PDT --- *** Bug 32662 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 18-04-2011 17:15, Jesse Barker escreveu: > One of the big issues we've been faced with at Linaro is around GPU > and multimedia device integration, in particular the memory management > requirements for supporting them on ARM. This next cycle, we'll be > focusing on driving consensus around a unified memory management > solution for embedded systems that support multiple architectures and > SoCs. This is listed as part of our working set of requirements for > the next six-month cycle (in spite of the URL, this is not being > treated as a graphics-specific topic - we also have participation from > multimedia and kernel working group folks): > > https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics As part of the memory management needs, Linaro organized several discussions during Linaro Development Summit (LDS), at Budapest, and invited me and other members of the V4L and DRI community to discuss about the requirements. I wish to thank Linaro for its initiative. Basically, on several SoC designs, the GPU and the CPU are integrated into the same chipset and they can share the same memory for a framebuffer. Also, they may have some IP blocks that allow processing the framebuffer internally, to do things like enhancing the image and converting it into an mpeg stream. The desire, from the SoC developers, is that those operations should be done using zero-copy transfers. This resembles somewhat the idea of the VIDIOC_OVERLAY/VIDIOC_FBUF API, that was used in the old days where CPUs weren't fast enough to process video without generating a huge load on it. So the overlay mode were created to allow direct PCI2PCI transfers from the video capture board into the display adapter, using XVideo extension, and removing the overload at the CPU due to a video stream. It were designed as a Kernel API for it, and an userspace X11 driver, that passes a framebuffer reference to the V4L driver, where it is used to program the DMA transfers to happen inside the framebuffer. At the LDS, we had a 3-day discussions about how the buffer sharing should be handled, and Linaro is producing a blueprint plan to address the needs. We had also a discussion about V4L and KMS, allowing both communities to better understand how things are supposed to work on the other side.
No subject
passing a framebuffer between two V4L2 devices and between a V4L2 device and GPU. The V4L2 device can either be an input or an output one. The original idea were to add yet-another-mmap-mode at the VIDIOC streaming ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed there, this would leed into sync issues on a shared buffer, causing flip effects. Also, as the API is generic, it can be used also on generic computers, like desktops, notebooks and tablets (even on arm-based designs), and it may end to be actually implemented as a PCI2PCI transfer. So, based at all I've seen, I'm pretty much convinced that the normal MMAP way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) are not the best way to share data with framebuffers. We probably need something that it will be an enhanced version of the VIDIOC_FBUF/VIDIOC_OVERLAY ioctls. Unfortunately, we can't just add more stuff there, as there's no reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. It seems to me that the proper way to develop such API is to start working with Xorg V4L driver, changing it to work with KMS and with the new API (probably porting some parts of the Xorg driver to kernelspace). One of the problems with a shared framebuffer is that an overlayed V4L stream may, at the worse case, be sent to up to 4 different GPU's and/or displays. Imagine a scenario like: ===+=== | | | | D1 +|---+ D2 | | | V4L| | | +-|+---|--| | || | | | D3 ++---+ D4 | | | | === Where D1, D2, D3 and D4 are 4 different displays, and the same V4L framebuffer is partially shared between them (the above is an example of a V4L input, although the reverse scenario of having one frame buffer divided into 4 V4L outputs also seems to be possible). As the same image may be divided into 4 monitors, the buffer filling should be synced with all of them, in order to avoid flipping effects. Also, the shared buffer can't be re-used until all displays finish reading. From what I understood from the discussions with DRI people, the display API's currently has similar issues of needing to wait for a buffer to be completely used before allowing it to be re-used. According to them, this were solved there by dynamically allocating buffers. We may need to do something similar to that also at V4L. Btw, the need of managing buffers is currently being covered by the proposal for new ioctl()s to support multi-sized video-buffers [1]. [1] http://www.spinics.net/lists/linux-media/msg30869.html It makes sense to me to discuss such proposal together with the above discussions, in order to keep the API consistent. On my understanding, the SoC people that are driving those changes will be working on providing the API proposals for it. They should also be providing the needed patches, open source drivers and userspace application(s) that allows testing and validating the GPU <==> V4L transfers using the newly API. Thanks, Mauro
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 14-05-2011 13:02, Hans Verkuil escreveu: > On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote: >> So, based at all I've seen, I'm pretty much convinced that the normal MMAP >> way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) >> are not the best way to share data with framebuffers. > > I agree with that, but it is a different story between two V4L2 devices. There > you obviously want to use the streaming ioctls and still share buffers. I don't think so. the requirement for syncing the framebuffer between the two V4L2 devices is pretty much the same as we have with one V4L2 device and one GPU. On both cases, the requirement is to pass a framebuffer between two entities, and not a video stream. For example, imagine something like: V4L2 camera => V4L2 encoder t MPEG2 || LL==> GPU Both GPU and the V4L2 encoder should use the same logic to be sure that they will use a buffer that were filled already by the camera. Also, the V4L2 camera driver can't re-use such framebuffer before being sure that both consumers has already stopped using it. So, it is the same requirement as having four displays receiving such framebuffer. Of course, a GPU endpoint may require some extra information for the blending, but also a V4L node may require some other type of extra information. >> We probably need >> something that it will be an enhanced version of the >> VIDIOC_FBUF/VIDIOC_OVERLAY >> ioctls. Unfortunately, we can't just add more stuff there, as there's no >> reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's. > > That will be useful as well to add better support for blending and Z-ordering > between overlays. The old API for that is very limited in that respect. Agreed. Mauro.
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #9 from Milan Plzik 2011-05-14 07:02:04 PDT --- Created an attachment (id=46709) View: https://bugs.freedesktop.org/attachment.cgi?id=46709 Review: https://bugs.freedesktop.org/review?bug=35998&attachment=46709 R300 texture alignment partial fix As Marek stated, this issue is related to texture alignment. After playing with mesa/src/gallium/drivers/r300/r300_texture_desc.c (see attached patch), I was able to get things rendering properly -- font issue disappeared with setting 'height' alignment of 8bpp textures to '2' and misrendered artifacts on some round edges with 32bpp textures and 'height' alignment to 2. Patch contains only values I needed to fix -- I guess there is some relation between parts of array I've been modifying. Unfortunately, this patch causes, that some (random) of GNOME 3's popup windows are being rendered improperly -- their content looks like portions of other textures (e.g. desktop background, icons, ...; random parts of vram), with no apparent relation to expected content. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37203] New: Tiny and Big: Menu is too bright
https://bugs.freedesktop.org/show_bug.cgi?id=37203 Summary: Tiny and Big: Menu is too bright Product: Mesa Version: git Platform: Other URL: http://www.tinyandbig.com/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se Created an attachment (id=46713) --> (https://bugs.freedesktop.org/attachment.cgi?id=46713) Screenshot of the bug The game Tiny and Big have a minor problem, after loading, the menu is too bright. This is probably not related to other too-bright bugs such as 37150 as r300g and llvmpipe renders the menu fine. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: ad2999d2113356d526b39774eb8114e974dac048 -- drm: 2.4.25 -- kernel: 2.6.39-rc7 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37203] Tiny and Big: Menu is too bright
https://bugs.freedesktop.org/show_bug.cgi?id=37203 --- Comment #1 from Sven Arvidsson 2011-05-14 08:09:13 PDT --- Created an attachment (id=46714) --> (https://bugs.freedesktop.org/attachment.cgi?id=46714) Correct rendering -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37193] Crash while switching between OpenGL window and other window
https://bugs.freedesktop.org/show_bug.cgi?id=37193 --- Comment #2 from Alex Deucher 2011-05-14 09:28:41 PDT --- Can you attach your xorg log and dmesg output? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #10 from Alex Deucher 2011-05-14 09:34:43 PDT --- RS600/RS690/RS740 require 64 bit texture pitch alignment, perhaps the tile alignment needs some adjustment as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #11 from Alex Deucher 2011-05-14 09:55:26 PDT --- *64 byte -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36268] [r300g, bisected] minor flickering in Unigine Sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=36268 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Ol??k 2011-05-14 11:05:52 PDT --- Fixed by 51095f74cf92d3cada7366ce898ade7693570b48. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g
https://bugs.freedesktop.org/show_bug.cgi?id=36609 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Marek Ol??k 2011-05-14 11:06:10 PDT --- Fixed by 51095f74cf92d3cada7366ce898ade7693570b48. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Wavering Arrandale output
* Chris Wilson [2011-05-14 08:55:15 +0100]: > On Fri, 13 May 2011 17:45:11 -0300, "Gustavo F. Padovan" profusion.mobi> wrote: > > Hi Chris, > > > > Bug #28306 is going to complete his first birthday at the end of this month, > > it is nagging around for a long time and I have many interest in fix this. > > > > So I tested your patch in duplicated bug #36599 and it doesn't work, but I > > managed to add some printks(see diff) there to help debug. > > > > [1.033866] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > > [1.033868] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > > [1.033869] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 1 > > [1.034120] [drm:intel_crtc_mode_set] *ERROR* is_lvds 1 > > [1.034121] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > > (null) > > [1.191465] [drm:intel_crtc_mode_set] *ERROR* 1. use_ssc 1 > > [1.191466] [drm:intel_crtc_mode_set] *ERROR* encoder->type 4 > > [1.191468] [drm:intel_crtc_mode_set] *ERROR* encoder->type 1 > > [1.191469] [drm:intel_crtc_mode_set] *ERROR* 2. use_ssc 0 > > [1.191720] [drm:intel_crtc_mode_set] *ERROR* is_lvds 0 > > [1.191721] [drm:intel_crtc_mode_set] *ERROR* has_edp_encoder > > (null) > > > > It seems your patch has no effect once has_edp_encoder is null. Can you > > please > > look into this? I can provide any test you may want, just send me the > > patches. > > ;) > > With no eDP on the system, we wouldn't expect to apply any of the eDP > settings. > > Even after your fix to the patch, nothing? Can you try just setting > use_ssc=0 (and keep your fix). Nothing. -- Gustavo F. Padovan http://profusion.mobi
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #12 from Milan Plzik 2011-05-14 14:04:05 PDT --- I'm sorry, I was talking about tile alignment whole time, the modified function was r300_get_pixel_alignment, which definitely returns "tile" . Sorry for confusion. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34252] Unexpected behaviour when switching video cards with vga_switcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=34252 Rafael J. Wysocki changed: What|Removed |Added Status|NEW |RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #12 from Rafael J. Wysocki 2011-05-14 22:19:01 --- Patch : https://bugzilla.kernel.org/attachment.cgi?id=57582 Handled-By : Florian Mickler -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 Rafael J. Wysocki changed: What|Removed |Added Status|NEW |NEEDINFO -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium
https://bugs.freedesktop.org/show_bug.cgi?id=36952 --- Comment #10 from dri tester 2011-05-14 17:55:51 PDT --- (In reply to comment #9) > Created an attachment (id=46696) View: https://bugs.freedesktop.org/attachment.cgi?id=46696 Review: https://bugs.freedesktop.org/review?bug=36952&attachment=46696 > possible fix > > Could you try this patch? The patch applied to latest mesa-git allows crackberg to run at the expected framerate with the expected cpu% for a few seconds (5-15 seconds), then it segfaults. The segfault might be caused by a different commit. Would it be worth bisecting again but applying the possible fix patch above each time before compiling to see if I can find another bad commit? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium
https://bugs.freedesktop.org/show_bug.cgi?id=36952 --- Comment #11 from Marek Ol??k 2011-05-14 18:08:28 PDT --- It would be better to experiment with the patch and try smaller buffer sizes. Please let me know when you find a size which works. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35095] [r300g] HiZ broken in WoW
https://bugs.freedesktop.org/show_bug.cgi?id=35095 --- Comment #9 from Marek Ol??k 2011-05-14 18:40:57 PDT --- Could you test the latest Mesa master branch? There are some new HiZ fixes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4
https://bugs.freedesktop.org/show_bug.cgi?id=36745 --- Comment #15 from Marek Ol??k 2011-05-14 19:07:14 PDT --- Andrew, could you please make an OpenGL trace file using apitrace? Get it here: https://github.com/apitrace/apitrace Compile it using cmake, then run something like: TRACE_FILE=/home/..user../3dmark.trace LD_PRELOAD=/path-to-apitrace/glxtrace.so ./executable where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me. That will capture all the 3D commands and I can replay it here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] drm: add overlays as first class KMS objects
On Fri, May 13, 2011 at 8:02 PM, Jesse Barnes wrote: > On Fri, 13 May 2011 18:16:30 +0200 > Daniel Vetter wrote: > >> Hi Jesse, >> >> Discussion here in Budapest with v4l and embedded graphics folks was >> extremely fruitful. A few quick things to take away - I'll try to dig >> through all >> the stuff I've learned more in-depth later (probably in a blog post or two): Hi Daniel, thanks for writing this up >> - embedded graphics is insane. The output routing/blending/whatever >> ? currently shipping hw can do is crazy and kms as-is is nowhere near up >> ? to snuff to support this. We've discussed omap4 and a ti chip targeted at >> ? video surveillance as use cases. I'll post block diagrams and explanations >> ? some when later. > > Yeah I expected that; even just TVs can have really funky restrictions > about z order and blend capability. > >> - we should immediately stop to call anything an overlay. It's a confusing >> ? concept that has a different meaning in every subsystem and for every hw >> ? manufacturer. More sensible names are dma fifo engines for things that >> slurp >> ? in planes and make them available to the display subsystem. Blend engines >> ? for blocks that take multiple input pipes and overlay/underlay/blend them >> ? together. Display subsytem/controller for the aggregate thing including >> ? encoders/resizers/outputs and especially the crazy routing network that >> ? connects everything. > > How about just "display plane" then? ?Specifically in the context of > display output hardware... "display plane" could be a good name.. actually in omap4 case it is a single dma engine that is multiplexing fetches for however many attached video pipes.. that is perhaps an implementation detail, but it makes "display plane" sound nicer as a name > >> 1) Splitting the crtc object into two objects: crtc with associated output >> mode >> (pixel clock, encoders/connectors) and dma engines (possibly multiple) that >> feed it. omap 4 has essentially just 4 dma engines that can be freely >> assigned >> to the available outputs, so a distinction between normal crtcs and overlay >> engines just does not make sense. There's the major open question of where >> to put the various attributes to set up the output pipeline. Also some of >> these >> attributes might need to be changed atomicly together with pageflips on >> a bunch of dma engines all associated with the same crtc on the next vsync, >> e.g. output position of an overlaid video buffer. > > Yeah, that's a good goal, and pretty much what I had in mind here. > However, breaking the existing interface is a non-starter, so either we > need a new CRTC object altogether, or we preserve the idea of a > "primary" plane (whatever that means for a given platform) that's tied > to each CRTC, which each additional plane described in a separate > structure. ?Z order and blend restrictions will have to be communicated > separately I think... In the cases I can think of, you'll always have a primary plane, so userspace need not explicitly specify it. But I think you want the driver to pick which display plane to be automatically hooked between the primary fb and crtc, or at least this should be the case if some new bit is set in driver_features to indicate the driver supports multiple display planes per crtc. BR, -R > Thanks, > -- > Jesse Barnes, Intel Open Source Technology Center >
