[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #6 from Krzysztof A. Sobiecki --- Around time, when I started using mesa:bb7ecb29fb6358a4c65278c2fe88936c578074cd, R600_LLVM=1 env var stopped causing GPU hang problems. I don't know if there is a link between this two facts, but for now I'm not willing to experiment with this(last time, when I have tried, computer crashed completely, not even pings and a package database have gone fishing). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/be16d4bf/attachment.html>
[Bug 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 --- Comment #3 from Krzysztof A. Sobiecki --- Created attachment 67856 --> https://bugs.freedesktop.org/attachment.cgi?id=67856=edit I'm so sorry for this thing. This patch hides problem with texture. It's a work in regress, do not use. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/0c9f4de6/attachment.html>
/dev/dri/card0 sometimes vanishes when I exit Xorg (Radeon RS780)
Hi, since a few weeks the /dev/dri/card0 entry sometimes vanishes when I exit Xorg. When I want to start Xorg again I get the following error message: ... [ 12711.547] (II) [KMS] Kernel modesetting enabled. [ 12711.548] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 12711.548] (II) RADEON(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 12711.548] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 12711.548] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 12711.548] (==) RADEON(0): Default visual is TrueColor [ 12711.548] (==) RADEON(0): RGB weight 888 [ 12711.548] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 12711.548] (--) RADEON(0): Chipset: "ATI Radeon HD 3300 Graphics" (ChipID = 0x9614) [ 12711.548] (II) RADEON(0): PCI card detected [ 12711.940] (EE) RADEON(0): [drm] Failed to open DRM device for pci::01:05.0: No such file or directory [ 12711.940] (EE) RADEON(0): Kernel modesetting setup failed [ 12711.940] (II) UnloadModule: "radeon" [ 12711.940] (EE) Screen(s) found, but none have a usable configuration. [ 12711.940] Fatal server error: [ 12711.940] no screens found I have to manually run "mdev -s" to restore the /dev/dri/card0 device. This happens with an Radeon RS780 and Xorg version 1.13.0 running the latest git kernel. /sys/class/drm/card0/device/power_profile is set to "auto" Is this a known problem? Are there any workarounds? -- Markus
[Bug 32535] [RADEON:KMS:RV710M:SUSPEND] graphics corruption after resume from hibernate on thinkpad SL510
https://bugs.freedesktop.org/show_bug.cgi?id=32535 --- Comment #8 from Alex Deucher --- Is this still an issue with a newer kernel? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/ac7e6331/attachment.html>
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #5 from Laurent carlier --- I can confirm, no lockups with R600_LLVM=0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/c6567a3a/attachment.html>
[Bug 32535] [RADEON:KMS:RV710M:SUSPEND] graphics corruption after resume from hibernate on thinkpad SL510
https://bugs.freedesktop.org/show_bug.cgi?id=32535 --- Comment #7 from jeroen__klomp at hotmail.com --- Hi, I can work around this problem by booting with "nomodeset". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/0c761d07/attachment.html>
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #4 from graham --- The code on line 510 of r600.c suggests that there is expected to be two power states for both POWER_STATE_TYPE_BATTERY and POWER_STATE_TYPE_PERFORMANCE, presumably one for single-head and one for multi-head. Changing the number to 0 (the first instance of the each power state) fixes the bug and allows low power mode. Could it be that there is actually only one power state for the HD6000? And the function radeon_pm_get_type_index in radeon_pm.c is failing to find the power state at index 1, and so is returning the default, high power state? Also, where would I find the list of power states found in radeon_atombios.c? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/1ca72c49/attachment.html>
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Op 28-09-12 22:10, Thomas Hellstrom schreef: > On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: >> On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: >>> Hey, >>> >>> Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. >>> >>> >>> The whole patch series is in my tree, I use stg so things might >>> move around, do not use for merging currently: >>> >>> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip >>> >>> It contains everything in here plus the patches for ttm to make >>> it work, I use a old snapshot of drm-next + merge of nouveau as >>> base. Description of what the parts do: >>> >>> Series to fix small api issues when moving over: >>> >>> drm/ttm: Remove cpu_writers related code >>> drm/ttm: Add ttm_bo_is_reserved function >>> drm/radeon: Use ttm_bo_is_reserved >>> drm/vmwgfx: use ttm_bo_is_reserved >>> >>> drm/vmwgfx: remove use of fence_obj_args >>> drm/ttm: remove sync_obj_arg >>> drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup >>> drm/ttm: remove sync_arg entirely >>> >>> drm/nouveau: unpin buffers before releasing to prevent lockdep warnings >>> drm/nouveau: add reservation to nouveau_bo_vma_del >>> drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep >>> >>> Hey great, now we only have one user left for fence waiting before >>> reserving, >>> lets fix that and remove fence lock: >>> ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before >>> waiting, lets do it in the squash commit so we don't have to throw lock >>> order >>> around everywhere: >>> >>> drm/ttm: remove fence_lock >>> >>> -- Up to this point should be mergeable now >>> >>> Then we start working on lru_lock removal slightly, this means the lru >>> list no longer is empty but can contain only reserved buffers: >>> >>> drm/ttm: do not check if list is empty in ttm_bo_force_list_clean >>> drm/ttm: move reservations for ttm_bo_cleanup_refs >>> >>> -- Still mergeable up to this point, just fixes >>> >>> Patch series from this email: >>> dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER >>> fence: dma-buf cross-device synchronization (v9) >>> seqno-fence: Hardware dma-buf implementation of fencing (v3) >>> reservation: cross-device reservation support >>> reservation: Add lockdep annotation and selftests >>> >>> Now hook it up to drm/ttm in a few steps: >>> usage around reservations: >>> drm/ttm: make ttm reservation calls behave like reservation calls >>> drm/ttm: use dma_reservation api >>> dma-buf: use reservations >>> drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo >>> >>> then kill off the lru lock around reservation: >>> drm/ttm: remove lru_lock around ttm_bo_reserve >>> drm/ttm: simplify ttm_eu_* >>> >>> The lru_lock removal patch removes the lock around lru_lock around the >>> reservation, this will break the assumption that items on the lru list >>> and swap list can always be reserved, and this gets patched up too. >>> Is there any part in ttm you disagree with? I believe that this >>> is all mergeable, the lru_lock removal patch could be moved to before >>> the reservation parts, this might make merging easier, but I don't >>> think there is any ttm part of the series that are wrong on a conceptual >>> level. >>> >>> ~Maarten >>> >> From another email >> As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. >>> The lru lock removal patch fixed the delayed delete code, it really is not >>> different from the current >>> situation. In fact it is more clear without the guarantee what various >>> parts are trying to protect. >>> >>> Nothing prevents you from holding the lru_lock while trylocking, >> [1] >> While this would not cause any deadlocks, Any decent lockdep code would >> establish lru->reserve as the locking >> order once a lru- reserve trylock succeeds, but the locking order is really >> reserve->lru for obvious reasons, which >> means we will get a lot of lockdep errors? Yes, there are a two reversals >> like these already in the TTM code, and I'm >> not very proud of them. >> >> leaving that guarantee intact for that part. Can you really just review >> the patch and tell me where it breaks and/or makes the code unreadable? >> >> OK. Now I'm looking at >> http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip=1436e2e64697c744d6e186618448e1e6354846bb >> >> And let's start with a function that's seen some change, ttm_mem_evict_first: >> >> *) Line 715: You're
[PATCH] radeon: don't take the stencil-specific codepath for buffers without stencil
---
radeon/radeon_surface.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 80b1505..03b1c5d 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -911,7 +911,7 @@ static int eg_surface_best(struct radeon_surface_manager
*surf_man,
* fmask buffer has different optimal value figure them out once we
* use it.
*/
-if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
+if (surf->flags & RADEON_SURF_SBUFFER) {
/* assume 1 bytes for stencil, we optimize for stencil as stencil
* and depth shares surface values
*/
--
1.7.9.5
[Bug 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #2 from Sven Arvidsson --- This might be a bug in the game itself: Mesa: User error: GL_INVALID_OPERATION in glCompressedTexImage2D(invalid width or height for compression format) If so, it isn't clear to me why it doesn't happen on the proprietary drivers as well? More information here: http://forums.runicgames.com/viewtopic.php?f=24=34893 The bug should probably be reassigned to Mesa core as this seems to happen with all Mesa drivers. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/a9023834/attachment.html>
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 --- Comment #2 from maxijac at free.fr --- Created attachment 67848 --> https://bugs.freedesktop.org/attachment.cgi?id=67848=edit tropics with colortiling2D on -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/5b4fc282/attachment.html>
[Bug 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 --- Comment #1 from maxijac at free.fr --- dmesg: [12040.432139] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.432144] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 [12040.432147] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.432256] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.432259] radeon :01:00.0: evergreen_packet3_check:2058 invalid cmd stream [12040.432261] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.450013] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.450019] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 [12040.450021] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.467709] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.467715] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 [12040.467717] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.480946] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.480951] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/001bcbc6/attachment.html>
[Bug 55448] New: [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 Priority: medium Bug ID: 55448 Assignee: dri-devel at lists.freedesktop.org Summary: [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics Severity: normal Classification: Unclassified OS: Linux (All) Reporter: maxijac at free.fr Hardware: All Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa I spotted this issue with unigine-tropics. The unigine window is all garbled, even the loading screen. Happens whenever I set the DDX to ColorTiling2D "on". When set to off, it works. I have the latest DDX & mesa of the time I'm posting this report for mesa it is 2.1 Mesa 9.1-devel (git-66159f9) for xf86-video-ati : e8cb0b721e6ea251f85c799ca0563bfa59a2d37c Linux 3.5.4 I'm using the LLVM compiler but with R600_LLVM=0 I have the same thing Unlike similars reports about the kernel rejecting CS, Glxgears and others random GL games don't have problems. Heaven is working correctly. If I have to bisect, tell me what, the DDX or mesa ? I'll post a screenshot. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/f88313ff/attachment.html>
[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()
On Friday 28 September 2012 01:09 PM, Maarten Lankhorst wrote:
> Op 28-09-12 09:29, Rob Clark schreef:
>> From: Rob Clark
>>
>> We never really clarified if unmap could be done in atomic context.
>> But since mapping might require sleeping, this implies mutex in use
>> to synchronize mapping/unmapping, so unmap could sleep as well. Add
>> a might_sleep() to clarify this.
>>
>> Signed-off-by: Rob Clark
>> Acked-by: Daniel Vetter
>> ---
>> drivers/base/dma-buf.c |2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>> index c30f3e1..877eacb 100644
>> --- a/drivers/base/dma-buf.c
>> +++ b/drivers/base/dma-buf.c
>> @@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
>> *attach,
>> struct sg_table *sg_table,
>> enum dma_data_direction direction)
>> {
>> +might_sleep();
>> +
>> if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
>> return;
>>
> Looks good to me!
>
> Reviewed-by: Maarten Lankhorst
Thanks Rob,
Applied to for-next.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[Intel-gfx] [PATCH 1/3] drm: Add an "expose 3d modes" property
On Thu, 27 Sep 2012 19:41:06 +0100, Damien Lespiau wrote:
> From: Damien Lespiau
>
> The "expose 3D modes" property can be attached to connectors to allow
> user space to indicate it can deal with 3D modes and that the drm driver
> should expose those 3D modes.
>
> Signed-off-by: Damien Lespiau
> ---
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bfacf0d..34372cb 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -578,6 +578,8 @@ struct drm_connector {
> /* requested DPMS state */
> int dpms;
>
> + int expose_3d_modes;
Looking at the surrounding code, this should be moved up and called
bool stereo_allowed;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 --- Comment #1 from Krzysztof A. Sobiecki --- Apitrace: pastelink.me/dl/4d477e -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/84f43c79/attachment-0001.html>
[Bug 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 Krzysztof A. Sobiecki changed: What|Removed |Added Attachment #67843|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/eaad2b8a/attachment.html>
[Bug 55445] New: Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445
Priority: medium
Bug ID: 55445
Assignee: dri-devel at lists.freedesktop.org
Summary: Torchlight: crash due to texture error
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: sobkas at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 67843
--> https://bugs.freedesktop.org/attachment.cgi?id=67843=edit
Problematic texture
When the Main Protagonist descends from Tu'tara Caverns Floor 19 via Stairs
Down into lover level, game crashes, with this message:
*-*-* Version 1.6.5 (Shoggoth)
terminate called after throwing an instance of 'Ogre::RenderingAPIException'
what(): OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface
on texture MEDIA/PARTICLES/TEXTURES/TRAIL/TRAIL37.DDS face 0 mipmap 2.
Probably, the GL driver refused to create the texture. in
GLTexture::_createSurfaceList at
../../../../RenderSystems/GL/src/OgreGLTexture.cpp (line 405)
./configure --prefix=/usr --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc
--libdir=${prefix}/lib/x86_64-linux-gnu --localstatedir=/v
ar --build=x86_64-linux-gnu --with-driver=dri --enable-r600-llvm-compiler
--with-dri-drivers= --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri
--with-dri-searchpath
=/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri --enable-glx-tls
--enable-shared-glapi --enable-texture-float --enable-xa --enable-driglx-direct
--with-eg
l-platforms=x11 drm --enable-gallium-llvm --with-gallium-drivers= nouveau r600
r300 svga swrast --enable-gles1 --enable-gles2 --enable-openvg
--enable-gallium-egl --d
isable-glu CFLAGS=-Wall -g -O2 CXXFLAGS=-Wall -g -O2
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 3.0 Mesa 9.1-devel
OpenGL shading language version string: 1.30
Linux solis 3.6.0-rc6+ #2 SMP Wed Sep 19 11:56:23 CEST 2012 x86_64 GNU/Linux
wheezy/sid
llvm-3.1:
Installed: 3.1-3~exp4
Candidate: 3.1-3~exp4
Version table:
*** 3.1-3~exp4 0
501 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
500 /var/lib/dpkg/status
3.1-2 0
501 http://ftp.pl.debian.org/debian/ unstable/main amd64 Packages
3.1-1 0
500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages
torchlight:
Installed: 1.0.20120924-1
Candidate: 1.0.20120924-1
Version table:
*** 1.0.20120924-1 0
500 /var/lib/dpkg/status
glxinfo |grep comp
GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture,
GL_ARB_texture_compression, GL_EXT_framebuffer_object,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_combine,
GL_ARB_texture_compression_rgtc, GL_ARB_texture_float,
GL_ARB_texture_rectangle, GL_ATI_texture_compression_3dc,
GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_rgtc,
GL_EXT_texture_compression_latc, GL_EXT_texture_integer,
GL_AMD_shader_stencil_export, GL_ARB_ES2_compatibility,
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/29ff17cc/attachment.html>
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416
--- Comment #4 from Krzysztof A. Sobiecki ---
I'm no longer able to reproduce this bug on
mesa:bb7ecb29fb6358a4c65278c2fe88936c578074cd.
Can someone confirm this?
I only had that bug, when I was using R600_LLVM=1(R600_LLVM=0 was safe).
There was a small visual difference between this two settings. R600_LLVM=1
caused rendering errors on main menu(not the missing face).
./configure --prefix=/usr --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc
--libdir=${prefix}/lib/x86_64-linux-gnu --localstatedir=/v
ar --build=x86_64-linux-gnu --with-driver=dri --enable-r600-llvm-compiler
--with-dri-drivers= --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri
--with-dri-searchpath
=/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri --enable-glx-tls
--enable-shared-glapi --enable-texture-float --enable-xa --enable-driglx-direct
--with-eg
l-platforms=x11 drm --enable-gallium-llvm --with-gallium-drivers= nouveau r600
r300 svga swrast --enable-gles1 --enable-gles2 --enable-openvg
--enable-gallium-egl --d
isable-glu CFLAGS=-Wall -g -O2 CXXFLAGS=-Wall -g -O2
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 3.0 Mesa 9.1-devel
OpenGL shading language version string: 1.30
Linux solis 3.6.0-rc6+ #2 SMP Wed Sep 19 11:56:23 CEST 2012 x86_64 GNU/Linux
wheezy/sid
llvm-3.1:
Installed: 3.1-3~exp4
Candidate: 3.1-3~exp4
Version table:
*** 3.1-3~exp4 0
501 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
500 /var/lib/dpkg/status
3.1-2 0
501 http://ftp.pl.debian.org/debian/ unstable/main amd64 Packages
3.1-1 0
500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages
torchlight:
Installed: 1.0.20120924-1
Candidate: 1.0.20120924-1
Version table:
*** 1.0.20120924-1 0
500 /var/lib/dpkg/status
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/f27f5a4f/attachment.html>
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #3 from Anthony Waters --- I bisected this a few days ago, the commit that causes the issue is c8b06dccff9cb89e20378664f3cbc202876a180f r600g: atomize framebuffer state -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120929/f5c10c59/attachment.html>
FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote: > > Final reminder: the deadline is tonight. > > So far there are three speakers who lined up, and my feeling is that > Matthieu and Marc lined up just so that the deadline and requirement > will be met. So only a single person is intending to come to fosdem and > has a topic he wants to talk about. > > Come on guys. Surely we can do better than that. > > Luc Verhaegen. After a bit of a scramble, we now have 7.5 speakers confirmed, and two pending budget/approval (which do not count towards the limit). I have therefor sent off the request to the organizers, there is little doubt that we will once again get a nice devroom next year :) We still have, i hope (depends on what the FOSDEM organizers have left for us), 6 slots fully open: first come first serve, and the earlier bird gets the nicer slot! Thanks all, especially those who stepped up already. Luc Verhaegen.
[PATCH libdrm 4/4] man: add drm-memory overview page
This adds an overview page that describes Dumb-Buffers, TTM and GEM. It
does not describe chipset-specific features. You should do that in the
driver-manpages.
Signed-off-by: David Herrmann
Reviewed-by: Jesse Barnes
---
man/Makefile.am| 9 +-
man/drm-memory.xml | 430 +
2 files changed, 437 insertions(+), 2 deletions(-)
create mode 100644 man/drm-memory.xml
diff --git a/man/Makefile.am b/man/Makefile.am
index ae02728..fb69c45 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -7,10 +7,14 @@
MANPAGES = \
drm.7 \
drm-kms.7 \
+ drm-memory.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
-MANPAGES_ALIASES =
+MANPAGES_ALIASES = \
+ drm-mm.7 \
+ drm-gem.7 \
+ drm-ttm.7
XML_FILES = \
${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)
@@ -32,7 +36,8 @@ XSLTPROC_FLAGS = \
XSLTPROC_PROCESS_MAN = \
$(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
- $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
+ $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $< && \
+ $(SED) -i -e 's/^\.so \(.*\)\.\(.\)$$/\.so man\2\/\1\.\2/'
$(MANPAGES_ALIASES)
%.1: %.xml
$(XSLTPROC_PROCESS_MAN)
diff --git a/man/drm-memory.xml b/man/drm-memory.xml
new file mode 100644
index 000..6b4f075
--- /dev/null
+++ b/man/drm-memory.xml
@@ -0,0 +1,430 @@
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;>
+
+
+
+
+
+Direct Rendering Manager
+libdrm
+September 2012
+
+
+Developer
+David
+Herrmann
+dh.herrmann at googlemail.com
+
+
+
+
+
+drm-memory
+7
+
+
+
+drm-memory
+drm-mm
+drm-gem
+drm-ttm
+DRM Memory Management
+
+
+
+
+ #include xf86drm.h
+
+
+
+
+Description
+ Many modern high-end GPUs come with their own memory managers. They
+even include several different caches that need to be synchronized
+during access. Textures, framebuffers, command buffers and more
need
+to be stored in memory that can be accessed quickly by the GPU.
+Therefore, memory management on GPUs is highly driver- and
+hardware-dependent.
+
+ However, there are several frameworks in the kernel that are used
by
+more than one driver. These can be used for trivial mode-setting
+without requiring driver-dependent code. But for
+hardware-accelerated rendering you need to read the manual pages
for
+the driver you want to work with.
+
+
+ Dumb-Buffers
+ Almost all in-kernel DRM hardware drivers support an API called
+Dumb-Buffers. This API allows to create
buffers
+of arbitrary size that can be used for scanout. These buffers can
be
+memory mapped via
+
mmap2
+so you can render into them on the CPU. However, GPU access to
these
+buffers is often not possible. Therefore, they are fine for simple
+tasks but not suitable for complex compositions and
+renderings.
+
+ The DRM_IOCTL_MODE_CREATE_DUMB ioctl can be
+used to create a dumb buffer. The kernel will return a 32bit handle
+that can be used to manage the buffer with the DRM API. You can
+create framebuffers with
+
drmModeAddFB3
+and use it for mode-setting and scanout. To access the buffer, you
+first need to retrieve the offset of the buffer. The
+DRM_IOCTL_MODE_MAP_DUMB ioctl requests the DRM
+subsystem to prepare the buffer for memory-mapping and returns a
+fake-offset that can be used with
+
mmap2.
+
+ The DRM_IOCTL_MODE_CREATE_DUMB ioctl takes as
+argument a structure of type
+struct drm_mode_create_dumb:
+
+
+struct drm_mode_create_dumb {
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
+
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
+};
+
+
+The fields height,
+width, bpp
and
+flags have to be provided by the caller.
+The other fields are filled by the kernel with the return values.
+height and
+width are the dimensions of the
+rectangular buffer that is created. bpp
+is the number of bits-per-pixel and must be a multiple of
+8. You most commonly want to pass
+32 here. The flags
+field is currently unused and must be zeroed. Different flags to
+modify the behavior may be added in the future. After calling the
+ioctl, the handle,
+pitch and
size
+
[PATCH libdrm 3/4] man: add drm-kms overview page
This is an overview page for KMS. It is again targeted at novice users that need redirection to the correct function man-pages. Signed-off-by: David Herrmann Reviewed-by: Jesse Barnes --- man/Makefile.am | 1 + man/drm-kms.xml | 342 2 files changed, 343 insertions(+) create mode 100644 man/drm-kms.xml diff --git a/man/Makefile.am b/man/Makefile.am index d55f444..ae02728 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -6,6 +6,7 @@ MANPAGES = \ drm.7 \ + drm-kms.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm-kms.xml b/man/drm-kms.xml new file mode 100644 index 000..5f04157 --- /dev/null +++ b/man/drm-kms.xml @@ -0,0 +1,342 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;> + + + + + +Direct Rendering Manager +libdrm +September 2012 + + +Developer +David +Herrmann +dh.herrmann at googlemail.com + + + + + +drm-kms +7 + + + +drm-kms +Kernel Mode-Setting + + + + + #include xf86drm.h + #include xf86drmMode.h + + + + +Description +Each DRM device provides access to manage which monitors and displays + are currently used and what frames to be displayed. This task is + called Kernel Mode-Setting (KMS). Historically, + this was done in user-space and called + User-space Mode-Setting (UMS). Almost all + open-source drivers now provide the KMS kernel API to do this in the + kernel, however, many non-open-source binary drivers from different + vendors still do not support this. You can use + drmModeSettingSupported3 + to check whether your driver supports this. To understand how KMS + works, we need to introduce 5 objects: CRTCs, + Planes, Encoders, + Connectors and + Framebuffers. + + + + CRTCs + +A CRTC short for + CRT Controller is an abstraction + representing a part of the chip that contains a pointer to a + scanout buffer. Therefore, the number of CRTCs available + determines how many independent scanout buffers can be active + at any given time. The CRTC structure contains several fields + to support this: a pointer to some video memory (abstracted as + a frame-buffer object), a list of driven connectors, a display + mode and an (x, y) offset into the video memory to support + panning or configurations where one piece of video memory + spans multiple CRTCs. A CRTC is the central point where + configuration of displays happens. You select which objects to + use, which modes and which parameters and then configure each + CRTC via + drmModeCrtcSet3 + to drive the display devices. + + + + Planes + +A plane respresents an image source that + can be blended with or overlayed on top of a CRTC during the + scanout process. Planes are associated with a frame-buffer to + crop a portion of the image memory (source) and optionally + scale it to a destination size. The result is then blended + with or overlayed on top of a CRTC. Planes are not provided by + all hardware and the number of available planes is limited. If + planes are not available or if not enough planes are + available, the user should fall back to normal software + blending (via GPU or CPU). + + + + Encoders + +An encoder takes pixel data from a CRTC + and converts it to a format suitable for any attached + connectors. On some devices, it may be possible to have a CRTC + send data to more than one encoder. In that case, both + encoders would receive data from the same scanout buffer, + resulting in a cloned display + configuration across the connectors attached to each + encoder. + + + + Connectors + +A connector is the final destination of + pixel-data on a device, and usually connects directly to an + external display device like a monitor or laptop panel. A + connector can only be attached to one encoder at a time. The + connector is also the structure where information about the + attached display is kept, so it contains fields for
[PATCH libdrm 2/4] man: add drm.7 overview page
The drm.xml file compiles to drm.7 and is meant as a global overview page for libdrm. It is targeted to new users of libdrm and redirects to all other main man-pages. Signed-off-by: David Herrmann Reviewed-by: Jesse Barnes --- man/Makefile.am | 1 + man/drm.xml | 137 2 files changed, 138 insertions(+) create mode 100644 man/drm.xml diff --git a/man/Makefile.am b/man/Makefile.am index 3030e5f..d55f444 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -5,6 +5,7 @@ # MANPAGES = \ + drm.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm.xml b/man/drm.xml new file mode 100644 index 000..5a49fe1 --- /dev/null +++ b/man/drm.xml @@ -0,0 +1,137 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;> + + + + + +Direct Rendering Manager +libdrm +September 2012 + + +Developer +David +Herrmann +dh.herrmann at googlemail.com + + + + + +drm +7 + + + +drm +Direct Rendering Manager + + + + + #include xf86drm.h + + + + +Description +The Direct Rendering Manager (DRM) is a framework + to manage Graphics Processing Units (GPUs). It is + designed to support the needs of complex graphics devices, usually + containing programmable pipelines well suited to 3D graphics + acceleration. Furthermore, it is responsible for memory management, + interrupt handling and DMA to provide a uniform interface to + applications. + +In earlier days, the kernel framework was solely used to provide raw + hardware access to priviledged user-space processes which implement + all the hardware abstraction layers. But more and more tasks where + moved into the kernel. All these interfaces are based on + ioctl2 + commands on the DRM character device. The libdrm + library provides wrappers for these system-calls and many helpers to + simplify the API. + +When a GPU is detected, the DRM system loads a driver for the detected + hardware type. Each connected GPU is then presented to user-space via + a character-device that is usually available as + /dev/dri/card0 and can be accessed with + open2 + and + close2. + However, it still depends on the grapics driver which interfaces are + available on these devices. If an interface is not available, the + syscalls will fail with EINVAL. + + + Authentication + All DRM devices provide authentication mechanisms. Only a DRM-Master +is allowed to perform mode-setting or modify core state and only one +user can be DRM-Master at a time. See + drmSetMaster3 +for information on how to become DRM-Master and what the limitations +are. Other DRM users can be authenticated to the DRM-Master via + drmAuthMagic3 +so they can perform buffer allocations and rendering. + + + + Mode-Setting + Managing connected monitors and displays and changing the current +modes is called Mode-Setting. This is +restricted to the current DRM-Master. Historically, this was +implemented in user-space, but new DRM drivers implement a kernel +interface to perform mode-setting called +Kernel Mode Setting (KMS). If your +hardware-driver supports it, you can use the KMS API provided by +DRM. This includes allocating framebuffers, selecting modes and +managing CRTCs and encoders. See + drm-kms7 +for more. + + + + Memory Management + The most sophisticated tasks for GPUs today is managing memory +objects. Textures, framebuffers, command-buffers and all other kinds +of commands for the GPU have to be stored in memory. The DRM driver +takes care of managing all memory objects, flushing caches, +synchronizing access and providing CPU access to GPU memory. All +memory management is hardware driver dependent. However, two generic +frameworks are available that are used by most DRM drivers. These +are the Translation Table Manager (TTM) and the +Graphics Execution Manager (GEM). They provide +generic APIs to create, destroy and access buffers from user-space. +However, there are still many differences between the drivers so +driver-depedent code is still needed. Many helpers are provided in +libgbm (Graphics Buffer Manager) from the +mesa-project. For more information on DRM +memory-management, see + drm-memory7. + + + + +Reporting Bugs +
[PATCH libdrm 1/4] man: convert manpages to XML instead of plain troff
If we want to use the manpages in external documentation other than normal
manpages, we should rather use XML. Furthermore, almost no-one knows troff
today, anyway, and XML allows others to easily add more pages without
having to learn troff.
Signed-off-by: David Herrmann
---
.gitignore | 4 ++
configure.ac| 24 +---
man/Makefile.am | 58 ++
man/drmAvailable.man| 25
man/drmAvailable.xml| 75
man/drmHandleEvent.man | 45 --
man/drmHandleEvent.xml | 102
man/drmModeGetResources.man | 79 -
man/drmModeGetResources.xml | 139
9 files changed, 370 insertions(+), 181 deletions(-)
delete mode 100644 man/drmAvailable.man
create mode 100644 man/drmAvailable.xml
delete mode 100644 man/drmHandleEvent.man
create mode 100644 man/drmHandleEvent.xml
delete mode 100644 man/drmModeGetResources.man
create mode 100644 man/drmModeGetResources.xml
diff --git a/.gitignore b/.gitignore
index 243457e..d297f94 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,9 @@
bsd-core/*/@
bsd-core/*/machine
+*.1
+*.3
+*.5
+*.7
*.flags
*.ko
*.ko.cmd
diff --git a/configure.ac b/configure.ac
index 290362c..7fd7f11 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,27 +35,6 @@ AM_MAINTAINER_MODE([enable])
# Enable quiet compiles on automake 1.11.
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
-if test x$LIB_MAN_SUFFIX = x; then
-LIB_MAN_SUFFIX=3
-fi
-if test x$LIB_MAN_DIR = x; then
-LIB_MAN_DIR='$(mandir)/man$(LIB_MAN_SUFFIX)'
-fi
-AC_SUBST([LIB_MAN_SUFFIX])
-AC_SUBST([LIB_MAN_DIR])
-
-MAN_SUBSTS="\
- -e 's|__vendorversion__|\"\$(PACKAGE_STRING)\" |' \
- -e 's|__projectroot__|\$(prefix)|g' \
- -e 's|__apploaddir__|\$(appdefaultdir)|g' \
- -e 's|__appmansuffix__|\$(APP_MAN_SUFFIX)|g' \
- -e 's|__drivermansuffix__|\$(DRIVER_MAN_SUFFIX)|g' \
- -e 's|__adminmansuffix__|\$(ADMIN_MAN_SUFFIX)|g' \
- -e 's|__libmansuffix__|\$(LIB_MAN_SUFFIX)|g' \
- -e 's|__miscmansuffix__|\$(MISC_MAN_SUFFIX)|g' \
- -e 's|__filemansuffix__|\$(FILE_MAN_SUFFIX)|g'"
-AC_SUBST([MAN_SUBSTS])
-
# Check for programs
AC_PROG_CC
@@ -235,6 +214,9 @@ if test "x$HAVE_LIBUDEV" = xyes; then
fi
AM_CONDITIONAL(HAVE_LIBUDEV, [test "x$HAVE_LIBUDEV" = xyes])
+AC_PATH_PROG(XSLTPROC, xsltproc)
+AM_CONDITIONAL([HAVE_XSLTPROC], [test "x$XSLTPROC" != "x"])
+
if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o
"x$OMAP" != "xno"; then
# Check for atomic intrinsics
AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
diff --git a/man/Makefile.am b/man/Makefile.am
index 73068e6..3030e5f 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,11 +1,47 @@
-libmandir = $(LIB_MAN_DIR)
-libman_PRE = drmAvailable.man \
- drmHandleEvent.man \
- drmModeGetResources.man
-libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@)
-EXTRA_DIST = $(libman_PRE)
-CLEANFILE = $(libman_DATA)
-SUFFIXES = .$(LIB_MAN_SUFFIX) .man
-
-.man.$(LIB_MAN_SUFFIX):
- $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
+#
+# This generates man-pages out of the Docbook XML files. Simply add your files
+# to the $MANPAGES array. If aliases are created, please add them to the
+# MANPAGES_ALIASES array so they get installed correctly.
+#
+
+MANPAGES = \
+ drmAvailable.3 \
+ drmHandleEvent.3 \
+ drmModeGetResources.3
+MANPAGES_ALIASES =
+
+XML_FILES = \
+ ${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)
+CLEANFILES =
+EXTRA_DIST =
+man_MANS =
+
+if HAVE_XSLTPROC
+
+CLEANFILES += $(MANPAGES) $(MANPAGES_ALIASES)
+EXTRA_DIST += $(MANPAGES) $(MANPAGES_ALIASES) $(XML_FILES)
+man_MANS += $(MANPAGES) $(MANPAGES_ALIASES)
+
+XSLTPROC_FLAGS = \
+ --stringparam man.authors.section.enabled 0 \
+ --stringparam man.copyright.section.enabled 0 \
+ --stringparam funcsynopsis.style ansi \
+ --stringparam man.output.quietly 1
+
+XSLTPROC_PROCESS_MAN = \
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
+ $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
+
+%.1: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.3: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.5: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.7: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+endif # HAVE_XSLTPROC
diff --git a/man/drmAvailable.man b/man/drmAvailable.man
deleted file mode 100644
index e1bb8dc..000
--- a/man/drmAvailable.man
+++ /dev/null
@@ -1,25 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmAvailable __drivermansuffix__ __vendorversion__
-.SH NAME
-drmAvailable \- determine whether a DRM kernel driver has been loaded
-.SH SYNOPSIS
-.nf
-.B "#include "
-
-.B "int drmAvailable(void);"
[PATCH libdrm 0/4] Manpages for libdrm
Hi This is revision 2 of the manpages for libdrm. I converted everything to docbook XML. This makes it easier to write them (troff is really hard to read) and allows us to integrate it into other documentation. Other than that I only fixed typos and the small corrections you guys mentioned. Thanks for reviewing! Regards David David Herrmann (4): man: convert manpages to XML instead of plain troff man: add drm.7 overview page man: add drm-kms overview page man: add drm-memory overview page .gitignore | 4 + configure.ac| 24 +-- man/Makefile.am | 65 +-- man/drm-kms.xml | 342 +++ man/drm-memory.xml | 430 man/drm.xml | 137 ++ man/drmAvailable.man| 25 --- man/drmAvailable.xml| 75 man/drmHandleEvent.man | 45 - man/drmHandleEvent.xml | 102 +++ man/drmModeGetResources.man | 79 man/drmModeGetResources.xml | 139 ++ 12 files changed, 1286 insertions(+), 181 deletions(-) create mode 100644 man/drm-kms.xml create mode 100644 man/drm-memory.xml create mode 100644 man/drm.xml delete mode 100644 man/drmAvailable.man create mode 100644 man/drmAvailable.xml delete mode 100644 man/drmHandleEvent.man create mode 100644 man/drmHandleEvent.xml delete mode 100644 man/drmModeGetResources.man create mode 100644 man/drmModeGetResources.xml -- 1.7.12.1
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416
--- Comment #4 from Krzysztof A. Sobiecki sob...@gmail.com ---
I'm no longer able to reproduce this bug on
mesa:bb7ecb29fb6358a4c65278c2fe88936c578074cd.
Can someone confirm this?
I only had that bug, when I was using R600_LLVM=1(R600_LLVM=0 was safe).
There was a small visual difference between this two settings. R600_LLVM=1
caused rendering errors on main menu(not the missing face).
./configure --prefix=/usr --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc
--libdir=${prefix}/lib/x86_64-linux-gnu --localstatedir=/v
ar --build=x86_64-linux-gnu --with-driver=dri --enable-r600-llvm-compiler
--with-dri-drivers= --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri
--with-dri-searchpath
=/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri --enable-glx-tls
--enable-shared-glapi --enable-texture-float --enable-xa --enable-driglx-direct
--with-eg
l-platforms=x11 drm --enable-gallium-llvm --with-gallium-drivers= nouveau r600
r300 svga swrast --enable-gles1 --enable-gles2 --enable-openvg
--enable-gallium-egl --d
isable-glu CFLAGS=-Wall -g -O2 CXXFLAGS=-Wall -g -O2
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 3.0 Mesa 9.1-devel
OpenGL shading language version string: 1.30
Linux solis 3.6.0-rc6+ #2 SMP Wed Sep 19 11:56:23 CEST 2012 x86_64 GNU/Linux
wheezy/sid
llvm-3.1:
Installed: 3.1-3~exp4
Candidate: 3.1-3~exp4
Version table:
*** 3.1-3~exp4 0
501 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
500 /var/lib/dpkg/status
3.1-2 0
501 http://ftp.pl.debian.org/debian/ unstable/main amd64 Packages
3.1-1 0
500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages
torchlight:
Installed: 1.0.20120924-1
Candidate: 1.0.20120924-1
Version table:
*** 1.0.20120924-1 0
500 /var/lib/dpkg/status
--
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 55445] New: Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445
Priority: medium
Bug ID: 55445
Assignee: dri-devel@lists.freedesktop.org
Summary: Torchlight: crash due to texture error
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: sob...@gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 67843
-- https://bugs.freedesktop.org/attachment.cgi?id=67843action=edit
Problematic texture
When the Main Protagonist descends from Tu'tara Caverns Floor 19 via Stairs
Down into lover level, game crashes, with this message:
*-*-* Version 1.6.5 (Shoggoth)
terminate called after throwing an instance of 'Ogre::RenderingAPIException'
what(): OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface
on texture MEDIA/PARTICLES/TEXTURES/TRAIL/TRAIL37.DDS face 0 mipmap 2.
Probably, the GL driver refused to create the texture. in
GLTexture::_createSurfaceList at
../../../../RenderSystems/GL/src/OgreGLTexture.cpp (line 405)
./configure --prefix=/usr --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc
--libdir=${prefix}/lib/x86_64-linux-gnu --localstatedir=/v
ar --build=x86_64-linux-gnu --with-driver=dri --enable-r600-llvm-compiler
--with-dri-drivers= --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri
--with-dri-searchpath
=/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri --enable-glx-tls
--enable-shared-glapi --enable-texture-float --enable-xa --enable-driglx-direct
--with-eg
l-platforms=x11 drm --enable-gallium-llvm --with-gallium-drivers= nouveau r600
r300 svga swrast --enable-gles1 --enable-gles2 --enable-openvg
--enable-gallium-egl --d
isable-glu CFLAGS=-Wall -g -O2 CXXFLAGS=-Wall -g -O2
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 3.0 Mesa 9.1-devel
OpenGL shading language version string: 1.30
Linux solis 3.6.0-rc6+ #2 SMP Wed Sep 19 11:56:23 CEST 2012 x86_64 GNU/Linux
wheezy/sid
llvm-3.1:
Installed: 3.1-3~exp4
Candidate: 3.1-3~exp4
Version table:
*** 3.1-3~exp4 0
501 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
500 /var/lib/dpkg/status
3.1-2 0
501 http://ftp.pl.debian.org/debian/ unstable/main amd64 Packages
3.1-1 0
500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages
torchlight:
Installed: 1.0.20120924-1
Candidate: 1.0.20120924-1
Version table:
*** 1.0.20120924-1 0
500 /var/lib/dpkg/status
glxinfo |grep comp
GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture,
GL_ARB_texture_compression, GL_EXT_framebuffer_object,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_combine,
GL_ARB_texture_compression_rgtc, GL_ARB_texture_float,
GL_ARB_texture_rectangle, GL_ATI_texture_compression_3dc,
GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_rgtc,
GL_EXT_texture_compression_latc, GL_EXT_texture_integer,
GL_AMD_shader_stencil_export, GL_ARB_ES2_compatibility,
--
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 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 Krzysztof A. Sobiecki sob...@gmail.com changed: What|Removed |Added Attachment #67843|text/plain |application/octet-stream mime type|| -- 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 55448] New: [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 Priority: medium Bug ID: 55448 Assignee: dri-devel@lists.freedesktop.org Summary: [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics Severity: normal Classification: Unclassified OS: Linux (All) Reporter: maxi...@free.fr Hardware: All Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa I spotted this issue with unigine-tropics. The unigine window is all garbled, even the loading screen. Happens whenever I set the DDX to ColorTiling2D on. When set to off, it works. I have the latest DDX mesa of the time I'm posting this report for mesa it is 2.1 Mesa 9.1-devel (git-66159f9) for xf86-video-ati : e8cb0b721e6ea251f85c799ca0563bfa59a2d37c Linux 3.5.4 I'm using the LLVM compiler but with R600_LLVM=0 I have the same thing Unlike similars reports about the kernel rejecting CS, Glxgears and others random GL games don't have problems. Heaven is working correctly. If I have to bisect, tell me what, the DDX or mesa ? I'll post a screenshot. -- 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 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 --- Comment #1 from maxi...@free.fr --- dmesg: [12040.432139] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.432144] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 [12040.432147] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.432256] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.432259] radeon :01:00.0: evergreen_packet3_check:2058 invalid cmd stream [12040.432261] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.450013] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.450019] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 [12040.450021] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.467709] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.467715] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 [12040.467717] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [12040.480946] radeon :01:00.0: evergreen_surface_value_conv_check:330 cb invalid array mode 6 [12040.480951] radeon :01:00.0: evergreen_packet3_check:2098 invalid cmd stream 595 -- 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 55448] [ColorTiling2D] R600 BARTS radeon: The kernel rejected CS and graphical corruption with tropics
https://bugs.freedesktop.org/show_bug.cgi?id=55448 --- Comment #2 from maxi...@free.fr --- Created attachment 67848 -- https://bugs.freedesktop.org/attachment.cgi?id=67848action=edit tropics with colortiling2D on -- 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 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 Sven Arvidsson s...@whiz.se changed: What|Removed |Added CC||s...@whiz.se --- Comment #2 from Sven Arvidsson s...@whiz.se --- This might be a bug in the game itself: Mesa: User error: GL_INVALID_OPERATION in glCompressedTexImage2D(invalid width or height for compression format) If so, it isn't clear to me why it doesn't happen on the proprietary drivers as well? More information here: http://forums.runicgames.com/viewtopic.php?f=24t=34893 The bug should probably be reassigned to Mesa core as this seems to happen with all Mesa drivers. -- 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
[PATCH] radeon: don't take the stencil-specific codepath for buffers without stencil
---
radeon/radeon_surface.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 80b1505..03b1c5d 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -911,7 +911,7 @@ static int eg_surface_best(struct radeon_surface_manager
*surf_man,
* fmask buffer has different optimal value figure them out once we
* use it.
*/
-if (surf-flags (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
+if (surf-flags RADEON_SURF_SBUFFER) {
/* assume 1 bytes for stencil, we optimize for stencil as stencil
* and depth shares surface values
*/
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Op 28-09-12 22:10, Thomas Hellstrom schreef: On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten From another email As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru-reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve-lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? OK. Now I'm looking at http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wipid=1436e2e64697c744d6e186618448e1e6354846bb And let's start with a function that's seen some change, ttm_mem_evict_first: *) Line 715: You're traversing a list using list_for_each() calling a function that may remove the list entry *) Line 722: You're unlocking the lock protecting the list in the middle of list traversal *) Line 507: WARN_ON_ONCE in a code path quite likely to get called? When will it get called? ttm_bo_delayed_delete calls it if it's already on delayed
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #4 from graham grhm.pe...@gmail.com --- The code on line 510 of r600.c suggests that there is expected to be two power states for both POWER_STATE_TYPE_BATTERY and POWER_STATE_TYPE_PERFORMANCE, presumably one for single-head and one for multi-head. Changing the number to 0 (the first instance of the each power state) fixes the bug and allows low power mode. Could it be that there is actually only one power state for the HD6000? And the function radeon_pm_get_type_index in radeon_pm.c is failing to find the power state at index 1, and so is returning the default, high power state? Also, where would I find the list of power states found in radeon_atombios.c? -- 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 32535] [RADEON:KMS:RV710M:SUSPEND] graphics corruption after resume from hibernate on thinkpad SL510
https://bugs.freedesktop.org/show_bug.cgi?id=32535 --- Comment #7 from jeroen__kl...@hotmail.com --- Hi, I can work around this problem by booting with nomodeset. -- 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 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #5 from Laurent carlier lordhea...@gmail.com --- I can confirm, no lockups with R600_LLVM=0 -- 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
/dev/dri/card0 sometimes vanishes when I exit Xorg (Radeon RS780)
Hi, since a few weeks the /dev/dri/card0 entry sometimes vanishes when I exit Xorg. When I want to start Xorg again I get the following error message: ... [ 12711.547] (II) [KMS] Kernel modesetting enabled. [ 12711.548] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 12711.548] (II) RADEON(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [ 12711.548] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 12711.548] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 12711.548] (==) RADEON(0): Default visual is TrueColor [ 12711.548] (==) RADEON(0): RGB weight 888 [ 12711.548] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 12711.548] (--) RADEON(0): Chipset: ATI Radeon HD 3300 Graphics (ChipID = 0x9614) [ 12711.548] (II) RADEON(0): PCI card detected [ 12711.940] (EE) RADEON(0): [drm] Failed to open DRM device for pci::01:05.0: No such file or directory [ 12711.940] (EE) RADEON(0): Kernel modesetting setup failed [ 12711.940] (II) UnloadModule: radeon [ 12711.940] (EE) Screen(s) found, but none have a usable configuration. [ 12711.940] Fatal server error: [ 12711.940] no screens found I have to manually run mdev -s to restore the /dev/dri/card0 device. This happens with an Radeon RS780 and Xorg version 1.13.0 running the latest git kernel. /sys/class/drm/card0/device/power_profile is set to auto Is this a known problem? Are there any workarounds? -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32535] [RADEON:KMS:RV710M:SUSPEND] graphics corruption after resume from hibernate on thinkpad SL510
https://bugs.freedesktop.org/show_bug.cgi?id=32535 --- Comment #8 from Alex Deucher ag...@yahoo.com --- Is this still an issue with a newer kernel? -- 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 55445] Torchlight: crash due to texture error
https://bugs.freedesktop.org/show_bug.cgi?id=55445 --- Comment #3 from Krzysztof A. Sobiecki sob...@gmail.com --- Created attachment 67856 -- https://bugs.freedesktop.org/attachment.cgi?id=67856action=edit I'm so sorry for this thing. This patch hides problem with texture. It's a work in regress, do not use. -- 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 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #6 from Krzysztof A. Sobiecki sob...@gmail.com --- Around time, when I started using mesa:bb7ecb29fb6358a4c65278c2fe88936c578074cd, R600_LLVM=1 env var stopped causing GPU hang problems. I don't know if there is a link between this two facts, but for now I'm not willing to experiment with this(last time, when I have tried, computer crashed completely, not even pings and a package database have gone fishing). -- 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
