dri-devel March 2011

dri-devel@lists.freedesktop.org

88 participants
477 discussions

[ANNOUNCE] libdrm 2.4.24
by Chris Wilson 01 Mar '11

01 Mar '11

In order to satisfy a dependency upon a new kernel parameter for mesa, it is time for a new release of libdrm. The usual bug fixes are a nice bonus. -Chris Ben Skeggs (3): nouveau: nvc0 drm has no concept of "notifier block" nouveau: split pushbuf macros specific to nv04-nv50 out, and add nvc0 nouveau: fix up reloc_emit() to accept NULL target buffer Benjamin Franzke (5): configure.ac: ac_define HAVE_RADEON modetest: Create buffers using libkms tests/modeprint: Remove needless dependency on drm_intel tests/modeprint: Output masks as hex numbers modetest: Do no flip twice to a current front buffer Chris Wilson (7): intel: Export CONSTANT_BUFFER addressing mode intel: Fallback to old exec if no mrb_exec is available intel: compile fix for previous commit after rebasing intel: Set the public handle after opening by name intel: Remember named bo intel: Add I915_PARAM_HAS_RELAXED_DELTA configure: Bump version to 2.4.24 Daniel Vetter (2): intel: fix relaxed tiling on gen2 intel: Fixup for the fix for relaxed tiling on gen2 nobled (1): libkms/radeon: Add backend git tag: 2.4.24 http://dri.freedesktop.org/libdrm/libdrm-2.4.24.tar.bz2 MD5: 8d802bf3b368f9fac0d7d17516a9436f libdrm-2.4.24.tar.bz2 SHA1: 7555a46a05c91c5d89a1efcb372fa7095a38d210 libdrm-2.4.24.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.24.tar.gz MD5: b52c4a28db725b639a4984a57e9ed144 libdrm-2.4.24.tar.gz SHA1: 03be8720b62ecb05747c6461010aa3fd735e0631 libdrm-2.4.24.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[PATCH] kms: Fix warning XNFprintf is deprecated (v2)
by Sedat Dilek 01 Mar '11

01 Mar '11

The first take of my patch missed the breakage against pre-1.10 xservers and now I know XNFasprintf() is not a 1:1 replacement for XNFprintf(). The idea for the fix seemed to be so obvious, but as usual "really" test the patch you are sending to any ML. I am awfully sorry for the overhasty bad hack. Thanks to Alan and Alex for the help to fix it correctly, now. Tested-By: Sedat Dilek <sedat.dilek(a)gmail.com> CC: Alan Coopersmith <alan.coopersmith(a)oracle.com> CC: Alex Deucher <alexdeucher(a)gmail.com> CC: Michel Dänzer <michel(a)daenzer.net> Signed-off-by: Sedat Dilek <sedat.dilek(a)gmail.com> --- src/radeon_kms.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/radeon_kms.c b/src/radeon_kms.c index 158dc57..adf9b70 100644 --- a/src/radeon_kms.c +++ b/src/radeon_kms.c @@ -409,8 +409,13 @@ static Bool radeon_open_drm_master(ScrnInfoPtr pScrn) goto out; } +#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1,9,99,901,0) + XNFasprintf(&busid, "pci:%04x:%02x:%02x.%d", + dev->domain, dev->bus, dev->dev, dev->func); +#else busid = XNFprintf("pci:%04x:%02x:%02x.%d", dev->domain, dev->bus, dev->dev, dev->func); +#endif info->dri2.drm_fd = drmOpen("radeon", busid); if (info->dri2.drm_fd == -1) { -- 1.7.4.1

2 1

[PATCH] drm: reorder drm_open_hash to remove padding on 64 bit builds
by Richard Kennedy 01 Mar '11

01 Mar '11

Remove 8 bytes of padding on 64 bit builds to reduce the size of drm_open_hash to 24 bytes, which also shrinks drm_object_file by 24 bytes (136 -> 112) allowing it to fit in one fewer cache lines and a smaller slab. Signed-off-by: Richard Kennedy <richard(a)rsk.demon.co.uk> --- patch against v2.6.38-rc6 compiled & tested on x86_64 with nouveau. regards Richard diff --git a/include/drm/drm_hashtab.h b/include/drm/drm_hashtab.h index 0af087a..ff2ab48 100644 --- a/include/drm/drm_hashtab.h +++ b/include/drm/drm_hashtab.h @@ -48,8 +48,8 @@ struct drm_open_hash { unsigned int size; unsigned int order; unsigned int fill; - struct hlist_head *table; int use_vmalloc; + struct hlist_head *table; };

1 0

[Bug 30776] New: Wine expects GL_VENDOR to identify the card vendor
by bugzilla-daemon＠freedesktop.org 01 Mar '11

01 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=30776 Summary: Wine expects GL_VENDOR to identify the card vendor Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: trivial Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: seppo.yli-olli(a)iki.fi Not sure whose bug this is but Wine's logic for figuring out which card we have currently uses the following piece of code to figure out which "hw_vendor" we have: if (strstr(gl_vendor_string, "ATI") || strstr(gl_vendor_string, "Advanced Micro Devices, Inc.") || strstr(gl_vendor_string, "X.Org R300 Project") || strstr(gl_renderer, "R100") || strstr(gl_renderer, "R200") || strstr(gl_renderer, "R300") || strstr(gl_renderer, "R600") || strstr(gl_renderer, "R700")) return HW_VENDOR_ATI; Now, this wasn't such a problem with classic driver, eg with r600c we had even double positive match. With r600g, however, renderer string says the exact chip name (which Wine uses after it has found the right branch of chip id's to search from) and GL_VENDOR is "X.org". This causes Wine to fail detection (and end up fallbacking in a rather boring fashion through HW_VENDOR_NVIDIA finally to Nouveau since it already *did* manage to detect that we're running Mesa). I'm not sure what exactly the GL_VENDOR string should say but I'm hoping something more distinguishing could be put there. The first two items in that list would imo be viable options but that's not to say something else couldn't be put in and make Wine detect "hw_vendor" based on that instead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
by bugzilla-daemon＠freedesktop.org 01 Mar '11

01 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #4 from Alex Deucher <agd5f(a)yahoo.com> 2011-02-28 18:56:24 PST --- Created an attachment (id=43951) View: https://bugs.freedesktop.org/attachment.cgi?id=43951 Review: https://bugs.freedesktop.org/review?bug=25871&attachment=43951 possible fix Does this patch help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 34822] New: [r300g, bisected] Unigine Sanctuary: texture corruption with RGTC format
by bugzilla-daemon＠freedesktop.org 01 Mar '11

01 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=34822 Summary: [r300g, bisected] Unigine Sanctuary: texture corruption with RGTC format Product: Mesa Version: unspecified Platform: Other URL: http://www.unigine.com/download/#sanctuary OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: pavel.ondracka(a)email.cz There is some texture corruption in Unigine Sanctuary v2.3, it looks almost like if you were watching very low quality video. 83ebc01c1dd1cd8a960a2a61fc7203f8312644d5 is the first bad commit commit 83ebc01c1dd1cd8a960a2a61fc7203f8312644d5 Author: Dave Airlie <airlied(a)redhat.com> Date: Fri Feb 25 09:24:15 2011 +1000 mesa/st: add RGTC format support. this just adds a format check + format conversion. Workaround is MESA_EXTENSION_OVERRIDE="-GL_ARB_texture_compression_rgtc -GL_EXT_texture_compression_rgtc". mesa: d1dbbf7bf41959df489195d11eb50f8222d293d3 GPU: RV530 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
by bugzilla-daemon＠freedesktop.org 01 Mar '11

01 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #3 from Alex Deucher <agd5f(a)yahoo.com> 2011-02-28 18:27:18 PST --- For point sampled textures, SQ_TEX_SAMPLER_WORD2_0.MC_COORD_TRUNCATE needs to be set to 1. The default behavior for texture addressing is to round unless that bit is set. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2011