dri-devel April 2011

dri-devel@lists.freedesktop.org

93 participants
440 discussions

[Bug 36065] New: r600g regression : vertex buffer alignement
by bugzilla-daemon＠freedesktop.org 08 Apr '11

08 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=36065 Summary: r600g regression : vertex buffer alignement Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: pelloux(a)gmail.com I have a simple app using vbo to render models. The VBO layout is : position (3 float), normal (3 float), color (3 char) This app was running perfectly until I updated libdrm/mesa to git version. Now the app still does not have any GL error set (checked with glGetError()), but its rendering is completely wrong. git-bisect pointed me to this commit : 0ed5bf668db24fb56b5b359399099c89531e2a0a "r600g: Request DWORD aligned vertex buffers." OS : Debian unstable (amd64) Radeon HD 4850 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 7

[Bug 31943] drm EDID checking is too strict
by bugzilla-daemon＠freedesktop.org 08 Apr '11

08 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=31943 --- Comment #12 from Alex Deucher <agd5f(a)yahoo.com> 2011-04-08 09:05:29 PDT --- (In reply to comment #11) > I've got the problem as well. I've got an older Hanns G JC199D, and apparently > nouveau doesn't like its checksum either. The edid parser is shared by all kms drm drivers. > Is this a version problem, btw? What is so offensive about these older EDID > versions that the drivers are crapping out on (other than the checksum)? Could > the code validate the other sections to at least *see* if the data is garbage > before throwing the whole block out? Ideally, we implement some basic sanity checks to avoid reading past the end of an edid with a bad checksum. Usually the checksum problems are something stupid like a vendor made a last minute change one of the fields or a tv/receiver mangles something when updating hdmi fields. IMHO, it would be better to use the EDID than not. -- 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

[PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
by Konrad Rzeszutek Wilk 08 Apr '11

08 Apr '11

These two patches are not strictly required but they do a bit of cleanup and also fix a false reporting issue when the kernel is compiled with CONFIG_DEBUG_DMA_API. Essentially the patchset modifies 'struct ttm_tt' and 'struct ttm_bo_device' to contain a pointer to 'struct device'. Passing of the 'struct device' is done via the 'tt_bo_device_init'. The 'struct device' is then used during the allocation/deallocation of pages when TTM_PAGE_FLAG_DMA32 flag is set. At first it seems that we would need to keep a copy of 'struct device' in the struct ttm_bo_device only and use that. However, when 'ttm_tt_destroy' is called it sets ttm->be (which contains the 'struct ttm_bo_device') to NULL so we cannot use it. Hence we copy the 'struct device' pointer to the 'struct ttm_tm' and keep it there. I've put the patches on: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/ttm.pci-api.v5 The testing was a bit difficult b/c I could not persuade the machine to unload either the nouveau or radeon driver (I had a serial console hooked so I figured it would fallback to that?). Ended up calling 'unbind' on the /sys/pci/.../$BDF/driver/[radeon,nouveau] to trigger the de-allocation path. Thomas, What is the best way to test vmw-gfx*? Does the Workstation (5?) support this particular frontend? Konrad Rzeszutek Wilk (2): ttm: Include the 'struct dev' when using the DMA API. ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device. drivers/gpu/drm/nouveau/nouveau_mem.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo.c | 4 +++- drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ++++++----- drivers/gpu/drm/ttm/ttm_tt.c | 5 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- include/drm/ttm/ttm_bo_driver.h | 7 ++++++- include/drm/ttm/ttm_page_alloc.h | 8 ++++++-- 8 files changed, 30 insertions(+), 15 deletions(-) The full diff: diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c index 26347b7..3706156 100644 --- a/drivers/gpu/drm/nouveau/nouveau_mem.c +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c @@ -412,7 +412,8 @@ nouveau_mem_vram_init(struct drm_device *dev) ret = ttm_bo_device_init(&dev_priv->ttm.bdev, dev_priv->ttm.bo_global_ref.ref.object, &nouveau_bo_driver, DRM_FILE_PAGE_OFFSET, - dma_bits <= 32 ? true : false); + dma_bits <= 32 ? true : false, + dev->dev); if (ret) { NV_ERROR(dev, "Error initialising bo driver: %d\n", ret); return ret; diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 9ead11f..371890c 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -517,7 +517,8 @@ int radeon_ttm_init(struct radeon_device *rdev) r = ttm_bo_device_init(&rdev->mman.bdev, rdev->mman.bo_global_ref.ref.object, &radeon_bo_driver, DRM_FILE_PAGE_OFFSET, - rdev->need_dma32); + rdev->need_dma32, + rdev->dev); if (r) { DRM_ERROR("failed initializing buffer object driver(%d).\n", r); return r; diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index af61fc2..278a2d3 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1526,12 +1526,14 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev, struct ttm_bo_global *glob, struct ttm_bo_driver *driver, uint64_t file_page_offset, - bool need_dma32) + bool need_dma32, + struct device *dev) { int ret = -EINVAL; rwlock_init(&bdev->vm_lock); bdev->driver = driver; + bdev->dev = dev; memset(bdev->man, 0, sizeof(bdev->man)); diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index 737a2a2..35849db 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -664,7 +664,7 @@ out: */ int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address) + dma_addr_t *dma_address, struct device *dev) { struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); struct page *p = NULL; @@ -685,7 +685,7 @@ int ttm_get_pages(struct list_head *pages, int flags, for (r = 0; r < count; ++r) { if ((flags & TTM_PAGE_FLAG_DMA32) && dma_address) { void *addr; - addr = dma_alloc_coherent(NULL, PAGE_SIZE, + addr = dma_alloc_coherent(dev, PAGE_SIZE, &dma_address[r], gfp_flags); if (addr == NULL) @@ -730,7 +730,7 @@ int ttm_get_pages(struct list_head *pages, int flags, printk(KERN_ERR TTM_PFX "Failed to allocate extra pages " "for large request."); - ttm_put_pages(pages, 0, flags, cstate, NULL); + ttm_put_pages(pages, 0, flags, cstate, NULL, NULL); return r; } } @@ -741,7 +741,8 @@ int ttm_get_pages(struct list_head *pages, int flags, /* Put all pages in pages list to correct pool to wait for reuse */ void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, - enum ttm_caching_state cstate, dma_addr_t *dma_address) + enum ttm_caching_state cstate, dma_addr_t *dma_address, + struct device *dev) { unsigned long irq_flags; struct ttm_page_pool *pool = ttm_get_pool(flags, cstate); @@ -757,7 +758,7 @@ void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, void *addr = page_address(p); WARN_ON(!addr || !dma_address[r]); if (addr) - dma_free_coherent(NULL, PAGE_SIZE, + dma_free_coherent(dev, PAGE_SIZE, addr, dma_address[r]); dma_address[r] = 0; diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 86d5b17..354f9d9 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -110,7 +110,7 @@ static struct page *__ttm_tt_get_page(struct ttm_tt *ttm, int index) INIT_LIST_HEAD(&h); ret = ttm_get_pages(&h, ttm->page_flags, ttm->caching_state, 1, - &ttm->dma_address[index]); + &ttm->dma_address[index], ttm->dev); if (ret != 0) return NULL; @@ -304,7 +304,7 @@ static void ttm_tt_free_alloced_pages(struct ttm_tt *ttm) } } ttm_put_pages(&h, count, ttm->page_flags, ttm->caching_state, - ttm->dma_address); + ttm->dma_address, ttm->dev); ttm->state = tt_unpopulated; ttm->first_himem_page = ttm->num_pages; ttm->last_lomem_page = -1; @@ -397,6 +397,7 @@ struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size, ttm->last_lomem_page = -1; ttm->caching_state = tt_cached; ttm->page_flags = page_flags; + ttm->dev = bdev->dev; ttm->dummy_read_page = dummy_read_page; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 10ca97e..803d979 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -322,11 +322,11 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) ttm_lock_set_kill(&dev_priv->fbdev_master.lock, false, SIGTERM); dev_priv->active_master = &dev_priv->fbdev_master; - ret = ttm_bo_device_init(&dev_priv->bdev, dev_priv->bo_global_ref.ref.object, &vmw_bo_driver, VMWGFX_FILE_PAGE_OFFSET, - false); + false, + dev->dev); if (unlikely(ret != 0)) { DRM_ERROR("Failed initializing TTM buffer object driver.\n"); goto out_err1; diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index efed082..2024a74 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -177,6 +177,7 @@ struct ttm_tt { tt_unpopulated, } state; dma_addr_t *dma_address; + struct device *dev; }; #define TTM_MEMTYPE_FLAG_FIXED (1 << 0) /* Fixed (on-card) PCI memory */ @@ -551,6 +552,7 @@ struct ttm_bo_device { struct list_head device_list; struct ttm_bo_global *glob; struct ttm_bo_driver *driver; + struct device *dev; rwlock_t vm_lock; struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES]; spinlock_t fence_lock; @@ -791,6 +793,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); * @file_page_offset: Offset into the device address space that is available * for buffer data. This ensures compatibility with other users of the * address space. + * @need_dma32: Allocate pages under 4GB + * @dev: 'struct device' of the PCI device. * * Initializes a struct ttm_bo_device: * Returns: @@ -799,7 +803,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); extern int ttm_bo_device_init(struct ttm_bo_device *bdev, struct ttm_bo_global *glob, struct ttm_bo_driver *driver, - uint64_t file_page_offset, bool need_dma32); + uint64_t file_page_offset, bool need_dma32, + struct device *dev); /** * ttm_bo_unmap_virtual diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index 8062890..ccb6b7a 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -37,12 +37,14 @@ * @cstate: ttm caching state for the page. * @count: number of pages to allocate. * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set). + * @dev: struct device for appropiate DMA accounting. */ int ttm_get_pages(struct list_head *pages, int flags, enum ttm_caching_state cstate, unsigned count, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * Put linked list of pages to pool. * @@ -52,12 +54,14 @@ int ttm_get_pages(struct list_head *pages, * @flags: ttm flags for page allocation. * @cstate: ttm caching state. * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set). + * @dev: struct device for appropiate DMA accounting. */ void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags, enum ttm_caching_state cstate, - dma_addr_t *dma_address); + dma_addr_t *dma_address, + struct device *dev); /** * Initialize pool allocator. */

5 21

[Bug 31943] drm EDID checking is too strict
by bugzilla-daemon＠freedesktop.org 08 Apr '11

08 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=31943 --- Comment #11 from Joe Sislow <nouveau(a)madopal.com> 2011-04-08 08:25:08 PDT --- I've got the problem as well. I've got an older Hanns G JC199D, and apparently nouveau doesn't like its checksum either. [ 83.297263] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 180 [ 83.297276] [drm:drm_edid_block_valid] *ERROR* Raw EDID: [ 83.297286] <3>00 ff ff ff ff ff ff 00 22 64 c6 04 c9 15 00 00 ........"d...... [ 83.297290] <3>10 10 01 03 81 26 1e 78 2a fd 56 a5 53 4a 9d 24 .....&.x*.V.SJ.$ [ 83.297294] <3>14 4f 54 bf ef 80 81 80 71 4f 81 40 01 01 01 01 .OT.....qO.@.... [ 83.297297] <3>01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 ......0*..Q.*@0p [ 83.297300] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 36 31 36 ..x-.........616 [ 83.297303] <3>47 4a 33 30 4a 41 35 35 37 37 00 00 00 fd 00 32 GJ30JA5577.....2 [ 83.297306] <3>4c 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc L.S... .... [ 83.297309] <3>00 4a 43 31 39 39 44 0a fd fe 41 01 a1 fd fd fd .JC199D...A..... Basically, what I'd like to suggest is that the driver uses whatever old standard resolution that the VESA drivers use. Because right now, the driver is crippling systems by choosing a resolution that is out of range for some monitors, and there's no way to get the display back. In the current Fedora build, even if all graphical booting is disabled, nouveau is still setting things out of range. The way I've worked around this was to switch to the nvidia driver (at least it doesn't set a strange resolution when it starts up), manually create an EDID.bin, fix the checksum, and tell xorg.conf to use that file instead of reading the EDID. I don't understand the boot process now where X is starting earlier, and I'm not sure if the Option "CustomEDID" "DFP-0:/path/to/edid.bin line would work for nouveau. If it does, it's a possible intermediary fix for people. It's not an easy one, as I had to manually correct the checksum. Is this a version problem, btw? What is so offensive about these older EDID versions that the drivers are crapping out on (other than the checksum)? Could the code validate the other sections to at least *see* if the data is garbage before throwing the whole block out? -- 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 35999] New: Tiny and Big: segfault in r300_update_ztop
by bugzilla-daemon＠freedesktop.org 08 Apr '11

08 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=35999 Summary: Tiny and Big: segfault in r300_update_ztop Product: Mesa Version: git Platform: Other URL: http://www.tinyandbig.com/games/upthatmountain/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Created an attachment (id=45306) --> (https://bugs.freedesktop.org/attachment.cgi?id=45306) backtrace The game Tiny and Big causes a segfault in r300_update_ztop when RADEON_HYPERZ is set. Bisecting leads to this: 4af3fe857dc07923af8786b434dee32d493b577e is the first bad commit commit 4af3fe857dc07923af8786b434dee32d493b577e Author: Marek Olšák <maraeo(a)gmail.com> Date: Tue Apr 5 17:57:02 2011 +0200 r300g: postpone fragment shader state validation until draw_vbo :040000 040000 ce221d2e9217e0c1a81321fa9404e4dbf67c24c7 c0cd5edc1f81b3bda5b09cda5bd4f2f15edf0f86 M src System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.9.4.901 (1.9.5 RC 1) -- mesa: de579a16298e29358fec08bd7cfe3e505674705a -- drm: 2.4.24 -- kernel: 2.6.38 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
by bugzilla-daemon＠freedesktop.org 07 Apr '11

07 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #7 from Johannes Obermayr <johannesobermayr(a)gmx.de> 2011-04-07 11:00:32 PDT --- After a second and third try (after reboots) I got: [drm] pdata=00000072 I assume it is the value I receive each time now. -- 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 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
by bugzilla-daemon＠freedesktop.org 07 Apr '11

07 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=36037 Johannes Obermayr <johannesobermayr(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #45373|0 |1 is obsolete| | --- Comment #6 from Johannes Obermayr <johannesobermayr(a)gmx.de> 2011-04-07 10:03:15 PDT --- Created an attachment (id=45392) --> (https://bugs.freedesktop.org/attachment.cgi?id=45392) dmesg dmesg output with applied Debugging patch -- 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 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
by bugzilla-daemon＠freedesktop.org 07 Apr '11

07 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #5 from Michel Dänzer <michel(a)daenzer.net> 2011-04-07 08:35:56 PDT --- Created an attachment (id=45386) View: https://bugs.freedesktop.org/attachment.cgi?id=45386 Review: https://bugs.freedesktop.org/review?bug=36037&attachment=45386 Debugging patch This patch (only compile tested) should print the pointer values before referencing them, and bail if one of them is NULL. This should also avoid the immediate crash, but it might still crash elsewhere later on. -- 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 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
by bugzilla-daemon＠freedesktop.org 07 Apr '11

07 Apr '11

https://bugs.freedesktop.org/show_bug.cgi?id=36037 --- Comment #4 from Michel Dänzer <michel(a)daenzer.net> 2011-04-07 07:51:26 PDT --- Thanks, but I mean modifying radeon_legacy_backlight_get_brightness() to print the value of each pointer before dereferencing it. If you don't know how to do that, I can try whipping up a test patch. -- 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

[PATCH] radeon: Fix KMS CP writeback on big endian machines.
by Michel Dänzer 07 Apr '11

07 Apr '11

From: Michel Dänzer <daenzer(a)vmware.com> This is necessary even with PCI(e) GART, and it makes writeback work even with AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth and other AGP bridges though. Signed-off-by: Michel Dänzer <daenzer(a)vmware.com> --- drivers/gpu/drm/radeon/radeon_fence.c | 2 +- drivers/gpu/drm/radeon/radeon_ring.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 171b0b2..2b0ee62 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -80,7 +80,7 @@ static bool radeon_fence_poll_locked(struct radeon_device *rdev) scratch_index = R600_WB_EVENT_OFFSET + rdev->fence_drv.scratch_reg - rdev->scratch.reg_base; else scratch_index = RADEON_WB_SCRATCH_OFFSET + rdev->fence_drv.scratch_reg - rdev->scratch.reg_base; - seq = rdev->wb.wb[scratch_index/4]; + seq = le32_to_cpu(rdev->wb.wb[scratch_index/4]); } else seq = RREG32(rdev->fence_drv.scratch_reg); if (seq != rdev->fence_drv.last_seq) { diff --git a/drivers/gpu/drm/radeon/radeon_ring.c b/drivers/gpu/drm/radeon/radeon_ring.c index 992d99d..55ea680 100644 --- a/drivers/gpu/drm/radeon/radeon_ring.c +++ b/drivers/gpu/drm/radeon/radeon_ring.c @@ -248,7 +248,7 @@ void radeon_ib_pool_fini(struct radeon_device *rdev) void radeon_ring_free_size(struct radeon_device *rdev) { if (rdev->wb.enabled) - rdev->cp.rptr = rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]; + rdev->cp.rptr = le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); else { if (rdev->family >= CHIP_R600) rdev->cp.rptr = RREG32(R600_CP_RB_RPTR); -- 1.7.4.1

2 1

← Newer
1
...
37
38
39
40
41
42
43
44
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2011