http://blog.gmane.org/gmane.comp.video.dri.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.video.dri.devel/69674 <pre>From: Dave Airlie &lt;airlied&lt; at &gt;redhat.com&gt; Just move its only caller into the same file as it and make it static. Signed-off-by: Dave Airlie &lt;airlied&lt; at &gt;redhat.com&gt; --- drivers/gpu/drm/radeon/radeon.h | 1 - drivers/gpu/drm/radeon/radeon_cs.c | 27 ++++++++++++++++++++++++++- drivers/gpu/drm/radeon/radeon_ring.c | 25 ------------------------- 3 files changed, 26 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 1dc3a4a..492654f 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h &lt; at &gt;&lt; at &gt; -848,7 +848,6 &lt; at &gt;&lt; at &gt; struct radeon_cs_parser { s32priority; }; -extern int radeon_cs_update_pages(struct radeon_cs_parser *p, int pg_idx); extern int radeon_cs_finish_pages(struct radeon_cs_parser *p); extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx); diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index c7d64a7..0137689 100644 --- a/drivers/gpu/drm/radeon/rade</pre> Dave Airlie 2012-05-26T16:42:27 http://comments.gmane.org/gmane.comp.video.dri.devel/69658 <pre>https://bugs.freedesktop.org/show_bug.cgi?id=50360 Bug #: 50360 Summary: flightgear has absymal performance with the llvm shader compiler Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel&lt; at &gt;lists.freedesktop.org ReportedBy: aaalmosss&lt; at &gt;gmail.com I get ~3 fps with the LLVM compiler, while I get ~20 fps with `R600_LLVM=0 fgfs`. The only setting on the 'rendering options' dialog that affects framerate is 'material shaders', when it's off, I get ~50 fps with both compilers. Other games perform around the same with the two compilers. </pre> bugzilla-daemon< at >freedesktop.org 2012-05-25T18:08:15 http://comments.gmane.org/gmane.comp.video.dri.devel/69638 <pre>Hi All, I realise it's been a while since this was last discussed, however I'd like to bring up kernel-side synchronization again. By kernel-side synchronization, I mean allowing multiple drivers/devices wanting to access the same buffer to do so without bouncing up to userspace to resolve dependencies such as "the display controller can't start scanning out a buffer until the GPU has finished rendering into it". As such, this is really just an optimization which reduces latency between E.g. The GPU finishing a rendering job and that buffer being scanned out. I appreciate this particular example is already solved on desktop graphics cards as the display controller and 3D core are both controlled by the same driver, so no "generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM Mali) and display controller tend to be driven by separate drivers, so some mechanism is needed to allow both drivers to synchronize their access to buffers. There are multiple ways synchronization can be achieved</pre> Tom Cooksey 2012-05-25T11:08:29 http://comments.gmane.org/gmane.comp.video.dri.devel/69634 <pre>From: Dave Airlie &lt;airlied&lt; at &gt;redhat.com&gt; include/linux/dma-buf.h: In function ‘dma_buf_vmap’: include/linux/dma-buf.h:260:1: warning: no return statement in function returning non-void [-Wreturn-type] Reported-by: wfg&lt; at &gt;linux.intel.com Signed-off-by: Dave Airlie &lt;airlied&lt; at &gt;redhat.com&gt; --- include/linux/dma-buf.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index d8c2865..506bb7b 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h &lt; at &gt;&lt; at &gt; -257,6 +257,7 &lt; at &gt;&lt; at &gt; static inline void dma_buf_kunmap(struct dma_buf *dmabuf, static inline void *dma_buf_vmap(struct dma_buf *dmabuf) { +return NULL; } static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) </pre> Dave Airlie 2012-05-25T09:04:17 http://comments.gmane.org/gmane.comp.video.dri.devel/69631 <pre>Here's the libdrm part of the atomic mode setting stuff. There's a new object I christened drmModePropertySet. It's an opaque object which is used to keep track of property changes for the user. Internally it's just a linked list of object_id/property_id/property_value tuples. The list is sorted based on object_id and property_id to avoid duplicates. The YUYV libkms patch is there just because my test app was more geared towards YUV than RGB, and I was too lazy to make the switch to RGB. I also stripped out a bunch of gunk from my test app and pushed the result to gitorious [1]. What it does is move/resize the plane and flips the CRTC fb at the same time using the new API. The app has a rudimentary keyboard control mechanism: 't' toggles an automatic test mode 's','z','x','c' move the plane 'S','Z','X','C' change the plane size 'f' fills the plane with a pattern, the color changes each time 'b' fills the plane with color bars 'l' loads a ppm (P6) image into the plane 'o' toggles the plane on/off 'q' quit</pre> ville.syrjala< at >linux.intel.com 2012-05-25T08:07:26 http://comments.gmane.org/gmane.comp.video.dri.devel/69623 <pre>https://bugs.freedesktop.org/show_bug.cgi?id=50338 Bug #: 50338 Summary: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel&lt; at &gt;lists.freedesktop.org ReportedBy: edwin+mesa&lt; at &gt;etorok.net Created attachment 62087 --&gt; https://bugs.freedesktop.org/attachment.cgi?id=62087 R600_DUMP_SHADERS=1 output Trying to reproduce bug #50325 on Mesa git caused this error: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Bug can be reproduced by one of these: build/glretrace lt-glyphy-demo.trace demo/glyphy-demo I get the translation failed error both with R600_LLVM=0, and R600_LLVM=1. I've attached the R600_DUMP_SHADER</pre> bugzilla-daemon< at >freedesktop.org 2012-05-25T07:21:23 http://comments.gmane.org/gmane.comp.video.dri.devel/69618 <pre>From: Alex Deucher &lt;alexander.deucher&lt; at &gt;amd.com&gt; Using the wrong union. Signed-off-by: Alex Deucher &lt;alexander.deucher&lt; at &gt;amd.com&gt; Cc: stable&lt; at &gt;vger.kernel.org --- drivers/gpu/drm/radeon/ni.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index b01c2dd..ce4e7cc 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c &lt; at &gt;&lt; at &gt; -865,7 +865,7 &lt; at &gt;&lt; at &gt; static void cayman_gpu_init(struct radeon_device *rdev) /* num banks is 8 on all fusion asics. 0 = 4, 1 = 8, 2 = 16 */ if (rdev-&gt;flags &amp; RADEON_IS_IGP) -rdev-&gt;config.evergreen.tile_config |= 1 &lt;&lt; 4; +rdev-&gt;config.cayman.tile_config |= 1 &lt;&lt; 4; else rdev-&gt;config.cayman.tile_config |= ((mc_arb_ramcfg &amp; NOOFBANK_MASK) &gt;&gt; NOOFBANK_SHIFT) &lt;&lt; 4; </pre> alexdeucher< at >gmail.com 2012-05-25T02:55:15 http://comments.gmane.org/gmane.comp.video.dri.devel/69617 <pre>These guys seem to be recently introduced: [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 17000000, was 12060000 [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 17070000, was 17000000 This is on my SNB Macbook Air. Everything seems to *work*, which makes me think: - that error isn't really so big a deal that you have to *SHOUT* about it. - I wonder how valid the discrepancy checking code is to begin with. Hmm? Linus </pre> Linus Torvalds 2012-05-25T02:27:04 http://comments.gmane.org/gmane.comp.video.dri.devel/69610 <pre>https://bugs.freedesktop.org/show_bug.cgi?id=50325 Bug #: 50325 Summary: Glyphy bad render on r600g (software render is fine) Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel&lt; at &gt;lists.freedesktop.org ReportedBy: edwin+mesa&lt; at &gt;etorok.net Created attachment 62078 --&gt; https://bugs.freedesktop.org/attachment.cgi?id=62078 apitrace (cf. https://github.com/apitrace/apitrace/tree/1.0) I just tried Glyphy on r600g and the output is very bad. Don't know if its Glyphy bug or Mesa bug, but if I force software rendering in Mesa then I do see the output. Attached screenshots of bad (r600g) and good (software render). The bad render was obtained by: demo/glyphy-demo The good one: LIBGL_ALWAYS_SOFTWARE=1 demo/glyphy-demo I tested on: OpenGL ven</pre> bugzilla-daemon< at >freedesktop.org 2012-05-24T21:56:46 http://comments.gmane.org/gmane.comp.video.dri.devel/69594 <pre>Hi all, I've got fed up with our sorry state of connector detection and rampant edid re and rere-reading. This patch series lays the groundwork in the drm helpers so that drivers can avoid all this madness (at least on working hw) and properly cache the edid. With the additional changes for drm/i915, the edid is now read _once_ per plug event (or at boot-up/resume time). A further step would be to integrate the hotplug handling into the driver itself and only call -&gt;detect on the connectors for which the irq handler received a hotplug event. By adding POLL_FORCE drivers can get back the old behaviour of calling -&gt;detect every time probe_single_connector is called from userspace. I've splattered that over all drivers where I've thought it might be required. Note though that setting this doesn't avoid all regressions - the regular output poll work will still ignore any connectors with POLL_HPD set. If a driver/hw with broken hpd got away due to this, this will break stuff. But that should be easy to fix b</pre> Daniel Vetter 2012-05-24T19:26:35 http://comments.gmane.org/gmane.comp.video.dri.devel/69585 <pre>This is some very early demo code for the atomic modesetting feature. According to my current plan there would be just one ioctl. You simply feed it an arbitrary list of object properties and the implementation will decice how it can apply those (for example, whether it can complete the operation truly atomically and/or asynchronously). So everything is a property. This means the ioctl should be able to handle all future requirements just as long as they can be expressed using properties that fit the current model. In order to be able to feed connector lists, gamma tables, etc. the ioctl has to accepts blobs. Just one blob per property for now. Not sure if that would be enough. I also extended range propeties to support signed values. The implementation has to provide five function pointers, and the operation goes roughly like this: ioctl() { funcs-&gt;begin for_each_prop funcs-&gt;set funcs-&gt;check if (!check_only) funcs-&gt;commit funcs-&gt;end } The begin function allocates some kind of state object that</pre> ville.syrjala< at >linux.intel.com 2012-05-24T20:16:41 http://comments.gmane.org/gmane.comp.video.dri.devel/69567 <pre>Currently the video sprites appear to get disabled on modeset more by accient than by design. With the current API that behaviour makes very little sense to me. You first enable some plane, and then it can get disabled due to some unrelated operation. So these patches change the behaviour so that planes survive a modeset. There's a new hook to make sure they get disabled when swithing back to fbdev to show a panic oops. </pre> ville.syrjala< at >linux.intel.com 2012-05-24T18:29:46 http://comments.gmane.org/gmane.comp.video.dri.devel/69565 <pre>I can easily trigger a crash in nouveau interrupt handler by unbinding and rebinding the GPU. The command used: echo $pci_device &gt; nouveau/unbind &amp;&amp; \ sleep 5 &amp;&amp; \ echo $pci_device &gt; nouveau/bind Kernel is 3.4.0 with modular drm/nouveau. GPU is NVidia nForce IGP (NV11) Unbinding seems to work fine, display switching back to VGA text mode. Rebinding the GPU slightly later causes the below trace: Bruno (analysis following below trace) [ 1432.012832] Console: switching to colour VGA+ 80x25 [ 1432.014796] drm: unregistered panic notifier [ 1432.014905] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 1432.026324] [drm] nouveau 0000:02:00.0: 0xAFD8: Parsing digital output script table [ 1432.026611] [drm] nouveau 0000:02:00.0: Restoring VGA fonts [ 1432.028353] [TTM] Finalizing pool allocator [ 1432.029325] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 1437.066950] [drm] nouveau 0000:02:00.0: Detected an NV10 generation card (0x01a000b1) [ 1437.068909] [drm] nouveau 0000:</pre> Bruno Prémont 2012-05-24T18:09:41 http://comments.gmane.org/gmane.comp.video.dri.devel/69547 <pre>Just a few small items caught in my net while trawling the code. </pre> ville.syrjala< at >linux.intel.com 2012-05-24T17:53:57 http://comments.gmane.org/gmane.comp.video.dri.devel/69520 <pre>The framebuffer helper panic notifier is unregistered, in drm_fb_helper_fini(), when kernel_fb_helper_list goes from being non-empty to empty. However, in drm_fb_helper_single_fb_probe(), it's possible for the panic notifier to be registered without an element being added to this list if a driver's probe function returns 0. Make sure that an attempt to add the panic notifier is made only when adding an element to kernel_fb_helper_list. Signed-off-by: Frank Binns &lt;frank.binns&lt; at &gt;imgtec.com&gt; --- This should hopefully have none of the whitespace damage introduced by my email client last time. drivers/gpu/drm/drm_fb_helper.c | 21 ++++++++++----------- 1 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index a0d6e89..d3764b3 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c &lt; at &gt;&lt; at &gt; -807,21 +807,20 &lt; at &gt;&lt; at &gt; int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper, printk(KERN_INFO "fb%d: %s frame bu</pre> Frank Binns 2012-05-24T13:37:53 http://comments.gmane.org/gmane.comp.video.dri.devel/69502 <pre>It is completely unnecessary to create fences before they are emitted, so remove it and a bunch of checks if fences are emitted or not. Signed-off-by: Christian König &lt;deathsimple&lt; at &gt;vodafone.de&gt; --- drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/gpu/drm/radeon/ni.c | 2 +- drivers/gpu/drm/radeon/r100.c | 4 +- drivers/gpu/drm/radeon/r200.c | 4 +- drivers/gpu/drm/radeon/r600.c | 4 +- drivers/gpu/drm/radeon/r600_blit_kms.c | 6 +-- drivers/gpu/drm/radeon/radeon.h | 11 +++-- drivers/gpu/drm/radeon/radeon_asic.h | 8 ++-- drivers/gpu/drm/radeon/radeon_benchmark.c | 10 +---- drivers/gpu/drm/radeon/radeon_fence.c | 42 ++++++------------ drivers/gpu/drm/radeon/radeon_ring.c | 19 +++++---- drivers/gpu/drm/radeon/radeon_sa.c | 2 +- drivers/gpu/drm/radeon/radeon_test.c | 66 ++++++++++++----------------- drivers/gpu/drm/radeon/radeon_ttm.c | 30 +++++-------- drivers/gpu</pre> Christian König 2012-05-24T07:49:05 http://comments.gmane.org/gmane.comp.video.dri.devel/69491 <pre>Entirely new class of fail for this one. The detailed timings are for normal CVT but the monitor really wanted CVT-R. Bugzilla: http://bugzilla.redhat/com/516471 Signed-off-by: Adam Jackson &lt;ajax&lt; at &gt;redhat.com&gt; --- drivers/gpu/drm/drm_edid.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5a18b0d..a9b14a1 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c &lt; at &gt;&lt; at &gt; -66,6 +66,8 &lt; at &gt;&lt; at &gt; #define EDID_QUIRK_FIRST_DETAILED_PREFERRED(1 &lt;&lt; 5) /* use +hsync +vsync for detailed mode */ #define EDID_QUIRK_DETAILED_SYNC_PP(1 &lt;&lt; 6) +/* Force reduced-blanking timings for detailed modes */ +#define EDID_QUIRK_FORCE_REDUCED_BLANKING(1 &lt;&lt; 7) struct detailed_mode_closure { struct drm_connector *connector; &lt; at &gt;&lt; at &gt; -120,6 +122,9 &lt; at &gt;&lt; at &gt; static struct edid_quirk { /* Samsung SyncMaster 22[5-6]BW */ { "SAM", 596, EDID_QUIRK_PREFER_LARGE_60 }, { "SAM", 638, EDID_QUIRK_PREFER_LARGE_60 }, + +/* ViewSonic V</pre> Adam Jackson 2012-05-23T20:26:54 http://comments.gmane.org/gmane.comp.video.dri.devel/69480 <pre>From: Alex Deucher &lt;alexander.deucher&lt; at &gt;amd.com&gt; Only override the ddc bus if the connector doesn't have a valid one. The existing code overrode the ddc bus for all connectors even if it had ddc bus. Fixes ddc on another XFX card with the same pci ids that was broken by the quirk overwriting the correct ddc bus. Reported-by: Mehdi Aqadjani Memar &lt;m.aqadjanimemar&lt; at &gt;student.ru.nl&gt; Signed-off-by: Alex Deucher &lt;alexander.deucher&lt; at &gt;amd.com&gt; --- drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index f21cb08..3f57c42 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c &lt; at &gt;&lt; at &gt; -440,7 +440,9 &lt; at &gt;&lt; at &gt; static bool radeon_atom_apply_quirks(struct drm_device *dev, */ if ((dev-&gt;pdev-&gt;device == 0x9498) &amp;&amp; (dev-&gt;pdev-&gt;subsystem_vendor == 0x1682) &amp;&amp; - (dev-&gt;pdev-&gt;subsystem_device == 0x2452)) { + (dev-&gt;pdev-&gt;subsystem_dev</pre> alexdeucher< at >gmail.com 2012-05-23T15:48:59 http://comments.gmane.org/gmane.comp.video.dri.devel/69433 <pre>Hi! This box has DisplayPort and VGA, but no LVDS. Product specs are at http://h10010.www1.hp.com/wwpc/us/en/sm/WF25a/12454-12454-321959-338927-3640406-4282707.html?dnr=1 and dmidecode output can be found at http://www.getslash.de/bug_attachments/dmidecode-t5740e.txt Signed-off-by: Jan-Benedict Glaw &lt;jbglaw&lt; at &gt;getslash.de&gt; --- drivers/gpu/drm/i915/intel_lvds.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 9c71183..9fadd64 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c &lt; at &gt;&lt; at &gt; -747,6 +747,14 &lt; at &gt;&lt; at &gt; static const struct dmi_system_id intel_no_lvds[] = { }, { .callback = intel_no_lvds_dmi_callback, +.ident = "Hewlett-Packard HP t5740e Thin Client", +.matches = { +DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), +DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin Client"), +}, +}, +{ +.callback = intel_no_lvds_dmi_callback, .ident = "Hewlett-Packard t5745", .matches = { </pre> Jan-Benedict Glaw 2012-05-22T13:21:53 http://comments.gmane.org/gmane.comp.video.dri.devel/69418 <pre>https://bugs.freedesktop.org/show_bug.cgi?id=50232 Bug #: 50232 Summary: screen redraw is wrong in sauerbraten with the llvm compiler Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel&lt; at &gt;lists.freedesktop.org ReportedBy: aaalmosss&lt; at &gt;gmail.com Ghost images of the previous frames stay on the screen. This seems to be independent of the quality settings in the game. This is printed to the console: Warning: R600 LLVM backend does not support indirect adressing. Falling back to TGSI backend. Tested with sauerbraten 0.0.20100728.dfsg+repack-3 (debian unstable) and mesa 7a75e7d6e85d27e102ff7e15583c33b1ce282fe4 </pre> bugzilla-daemon< at >freedesktop.org 2012-05-22T20:00:36 http://comments.gmane.org/gmane.comp.video.dri.devel/69417 <pre>https://bugs.freedesktop.org/show_bug.cgi?id=50230 Bug #: 50230 Summary: offset mapping in nexuiz results in bad texturing with the llvm compiler Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel&lt; at &gt;lists.freedesktop.org ReportedBy: aaalmosss&lt; at &gt;gmail.com tested with nexuiz 2.5.2 and mesa 7a75e7d6e85d27e102ff7e15583c33b1ce282fe4 </pre> bugzilla-daemon< at >freedesktop.org 2012-05-22T12:48:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.dri.devel