Re: [PATCH] vgaarb: use bridges to control VGA routing where possible.
On 16/12/2010 05:54, Dave Airlie wrote:
From: Dave Airlie
int pci_set_vga_state(struct pci_dev *dev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
{
struct pci_bus *bus;
struct pci_dev *bridge;
u16 cmd;
int rc;
- WARN_ON(command_bits& ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY));
+ WARN_ON((flags& PCI_VGA_STATE_CHANGE_DECODES)& (command_bits&
~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
Minor thing, but I think the middle & should be a &&?
MM
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] TI DMM-TILER driver
On Monday 06 December 2010, David Sin wrote: > Tiling and Isometric Lightweight Engine for Rotation (TILER) driver > = > > Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. > Within the DMM exists at least one TILER hardware component. Its purpose is > to > organize video/image memory in a 2-dimensional fashion to limit memory > bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver > facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the > TILER container(s). It also facilitates rotating and mirroring the allocated > blocks or its rectangular subsections. How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality. I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32439] New: invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 Summary: invisible objects on r600g (probably shader issue) Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hramr...@centrum.cz Created an attachment (id=41168) --> (https://bugs.freedesktop.org/attachment.cgi?id=41168) dumped shaders Last time this happened it was due to some shaders failing to compile. Mesa does not report failed shader compilation so I will try to attach all shaders the program compiled. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] vgaarb: use bridges to control VGA routing where possible.
2010/12/16 Mark Marshall :
> On 16/12/2010 05:54, Dave Airlie wrote:
>>
>> From: Dave Airlie
>> int pci_set_vga_state(struct pci_dev *dev, bool decode,
>> - unsigned int command_bits, bool change_bridge)
>> + unsigned int command_bits, u32 flags)
>> {
>> struct pci_bus *bus;
>> struct pci_dev *bridge;
>> u16 cmd;
>> int rc;
>>
>> - WARN_ON(command_bits& ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY));
>> + WARN_ON((flags& PCI_VGA_STATE_CHANGE_DECODES)& (command_bits&
>> ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
>
> Minor thing, but I think the middle & should be a &&?
Dave: as you are going to fix patch, please add spaces around "|" by the way:
PCI_COMMAND_IO|PCI_COMMAND_MEMORY
--
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #20 from Álmos 2010-12-16 06:12:18 PST --- Created an attachment (id=41170) View: https://bugs.freedesktop.org/attachment.cgi?id=41170 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41170 r300g_multitexturing.diff I played around with the tmu texture cache region assignment code, read the corresponding part of the r3xx register manual, and deduced the following: - you must assign different region for different textures - assigned regions must not overlap The existing code guarantees none of these, especially if there are partial updates (which are quite common). The texture corruption is the result of the tmu loading different textures into the same cache area (possibly in different formats), and only one of them won't be garbage. This only applies to r3xx and r4xx, because r5xx ignores this parameter and assigns cache automatically. My patch doesn't guarantee anything either, is meant to be a proof-of-concept (or more like a hackload of hacky hacks), that almost completely fixes texturing in ut2004, vastly improves the situation in etqw (the corruption occurs only on strogg architecture and vehicles instead of almost everywhere), and changes nothing in googleearth. Doom3 would also be a good test, but it crashes since I increased GART from 64MB to 256MB. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/vmwgfx: Let SVGA_REG_NUM_DISPLAYS decide output connectivity
Makes the user able to determine the number of connected outputs from
the VMware GUI.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 29113c9..335c91c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -340,9 +340,16 @@ static enum drm_connector_status
vmw_ldu_connector_detect(struct drm_connector *connector,
bool force)
{
- if (vmw_connector_to_ldu(connector)->pref_active)
- return connector_status_connected;
- return connector_status_disconnected;
+ uint32_t num_displays;
+ struct drm_device *dev = connector->dev;
+ struct vmw_private *dev_priv = vmw_priv(dev);
+
+ mutex_lock(&dev_priv->hw_mutex);
+ num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS);
+ mutex_unlock(&dev_priv->hw_mutex);
+
+ return ((vmw_connector_to_ldu(connector)->base.unit < num_displays) ?
+ connector_status_connected : connector_status_disconnected);
}
static struct drm_display_mode vmw_ldu_connector_builtin[] = {
--
1.6.2.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 --- Comment #1 from Michal Suchanek 2010-12-16 06:30:01 PST --- Can't run the same program on r600c but it works on Mesa 7.9 r300g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 --- Comment #2 from Michal Suchanek 2010-12-16 06:54:21 PST --- Created an attachment (id=41175) --> (https://bugs.freedesktop.org/attachment.cgi?id=41175) difference between r600 shaders and swrastg shaders It works with swrastg and there is diference in size of arrays. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #21 from Marek Olšák 2010-12-16 07:00:56 PST --- (In reply to comment #20) > Created an attachment (id=41170) View: https://bugs.freedesktop.org/attachment.cgi?id=41170 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41170 > r300g_multitexturing.diff > > I played around with the tmu texture cache region assignment code, read the > corresponding part of the r3xx register manual, and deduced the following: > - you must assign different region for different textures > - assigned regions must not overlap > The existing code guarantees none of these, especially if there are partial > updates (which are quite common). The texture corruption is the result of the > tmu loading different textures into the same cache area (possibly in different > formats), and only one of them won't be garbage. Thanks a lot for looking into this, but let's discuss it a bit. Could you give me a prove that the current code is wrong? At least one case where the assignment of texture cache regions is done wrong. Currently it should assign the regions as follows: 1 texture: R300_TX_CACHE_WHOLE 2 textures: R300_TX_CACHE_HALF_0 R300_TX_CACHE_HALF_1 3 textures: R300_TX_CACHE_HALF_1 R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 4 textures: R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 5 textures: R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 6 textures: R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 7 textures: R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 R300_TX_CACHE_EIGHTH_4 R300_TX_CACHE_EIGHTH_5 8 textures: R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 R300_TX_CACHE_EIGHTH_4 R300_TX_CACHE_EIGHTH_5 R300_TX_CACHE_EIGHTH_6 R300_TX_CACHE_EIGHTH_7 And so on. I can't see any overlapping regions. It always divides the whole texture cache between all the textures. The code assumes each region can be divided to two of half the size of the original one. E.g. the case with 2 textures is: R300_TX_CACHE_HALF_0 R300_TX_CACHE_HALF_1 And when you add the 3rd texture, the first region will get divided evenly like this: R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_HALF_1 Does it look wrong to you? Do you think that the hardware doesn't like so _tight_ configuration of the regions? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24932] BUG: unable to handle kernel paging request
https://bugzilla.kernel.org/show_bug.cgi?id=24932 --- Comment #4 from Lars-Dominik Braun 2010-12-16 15:02:49 --- > Yes please, it would be useful to know if 2.6.35 had the same bug. 2.6.35.9 (vanilla) works fine. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 Michel Dänzer changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 Jerome Glisse changed: What|Removed |Added Attachment #41168|shaders.log |shaders.txt filename|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32422] Large images displayed in Firefox appear corrupted
https://bugs.freedesktop.org/show_bug.cgi?id=32422 --- Comment #8 from Michel Dänzer 2010-12-16 08:40:47 PST --- (In reply to comment #7) > Even with the patch for bug 31708 applied, I see the same corruption in > firefox [...] That's with the latest version (v3) of the patch? (Jerome even submitted v4 later, but I don't think the difference from v3 should be relevant for this problem; wouldn't hurt to try of course) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] TI DMM-TILER driver
On Thursday 16 December 2010 18:37:38 David Sin wrote: > I'm not sure exactly how DRM/GEM works.. What functionality do you think is > overlapping? The main feature, aside from reduced page accesses, of the DMM > hw block is to provide physically contiguous 2 dimensional memory blocks for > image and video processing. This hw sits between the interconnect and the > ext memory interface in the OMAP, and contains an MMU-like address traslator > for "virtually" physically contiguous memory and sdram pages. As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory. I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32447] New: GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 Summary: GPU lockup with Braid Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ma...@juffo.org When trying to run the "Braid" game, recently released for Linux as part of the Humble Indie Bundle, I see the game with corrupt graphics, and a segfault crash after a short while. After several such tries, it started locking up the GPU. I'm using Radeon HD 4870 (RV770) on 64-bit Arch Linux. The game is 32-bit. In order to run this game in the first place, I had to set force_s3tc_enable in drirc and install the libtxc_dxtn library. Versions: kernel 2.6.36.2 xorg-server 1.9.2 ati-dri 7.9.0.git20101207 mesa 7.9.0.git20101207 xf86-video-ati 6.13.2 glproto 1.4.12 At first when I run it I get: % gdb --args ./braid -windowed (gdb) run unsupported texture format in setup_hardware_state failed to validate texture for unit 0. ... ^ repeats lots of times Program received signal SIGSEGV, Segmentation fault. 0xf63e40ed in radeonEmitVec4 () from /usr/lib32/xorg/modules/dri/r600_dri.so (gdb) bt #0 0xf63e40ed in radeonEmitVec4 () from /usr/lib32/xorg/modules/dri/r600_dri.so #1 0xf63c1fbe in r700DrawPrims () from /usr/lib32/xorg/modules/dri/r600_dri.so #2 0xf64ab187 in vbo_exec_DrawArrays () from /usr/lib32/xorg/modules/dri/r600_dri.so #3 0xf64a1797 in neutral_DrawArrays () from /usr/lib32/xorg/modules/dri/r600_dri.so #4 0x081974cb in Display_System_OGL::immediate_flush() () #5 0x080cdfd1 in draw_intro_notification(float, char*, char*) () #6 0x080cf9e4 in draw_overlays_for_gameplay() () #7 0x080d0c2a in draw_world_view() () #8 0x080eaed1 in draw_game_mode() () #9 0x080eda1e in app_main(int, char**) () #10 0x0815223e in main () After a few tries, I start getting these GPU lockups, which turn my screen into a garbled mess. After a while the desktop environment re-appears, but then crashes again and finally suspends both my screens. I can switch to a VT terminal and 'kill -9 braid'. When switching back to Xorg, everything is back to normal. :) Here's from dmesg: radeon :01:00.0: GPU lockup CP stall for more than 1msec radeon :01:00.0: GPU lockup CP stall for more than 1msec [ cut here ] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x376/0x3e0 [radeon]() Hardware name: System Product Name GPU lockup (waiting for 0x0001D61D last fence id 0x0001D61C) Modules linked in: fuse ip6table_filter ip6_tables xt_CHECKSUM bridge stp llc hwmon_vid cpufreq_ondemand sit tunnel4 iptable_mangle xt_state ipt_REJECT xt_NFQUEUE iptable_filter ipt_REDIRECT xt_tcpudp ipt_MASQUERADE xt_owner iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables btrfs zlib_deflate crc32c libcrc32c usbhid hid snd_hda_codec_atihdmi usb_storage snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_via radeon snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd ttm soundcore snd_page_alloc drm_kms_helper drm i2c_piix4 i2c_algo_bit i2c_core ohci_hcd dm_mod ehci_hcd edac_core edac_mce_amd evdev sg asus_atk0110 parport_pc usbcore ppdev button thermal psmouse wmi serio_raw shpchp pci_hotplug k10temp lp parport kvm_amd kvm r8169 mii powernow_k8 freq_table processor mperf ipv6 autofs4 ext4 mbcache jbd2 crc16 sr_mod cdrom floppy pata_atiixp pata_acpi sd_mod ahci libahci libata scsi_mod Pid: 3274, comm: X Not tainted 2.6.36-ARCH #1 [ cut here ] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x376/0x3e0 [radeon]() Hardware name: System Product Name GPU lockup (waiting for 0x0001D61F last fence id 0x0001D61C) Modules linked in: fuse ip6table_filter ip6_tables xt_CHECKSUM bridge stp llc hwmon_vid cpufreq_ondemand sit tunnel4 iptable_mangle xt_state ipt_REJECT xt_NFQUEUE iptable_filter ipt_REDIRECT xt_tcpudp ipt_MASQUERADE xt_owner iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables btrfs zlib_deflate crc32c libcrc32c usbhid hid snd_hda_codec_atihdmi usb_storage snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_via radeon snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd ttm soundcore snd_page_alloc drm_kms_helper drm i2c_piix4 i2c_algo_bit i2c_core ohci_hcd dm_mod ehci_hcd edac_core edac_mce_amd evdev sg asus_atk0110 parport_pc usbcore ppdev button thermal psmouse wmi serio_raw shpchp pci_hotplug k10temp lp parport kvm_amd kvm r8169 mii powernow_k8 freq_table processor mperf ipv6 autofs4 ext4 mbcache jbd2 crc16 sr_mod cdrom floppy pata_atiixp pata_acpi sd_mod ahci libahci libata scsi_mod Pid: 3830, comm: braid Not tainted
[Bug 32447] GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 --- Comment #1 from Marti 2010-12-16 10:30:25 PST --- Another data point, when running with MESA_DEBUG=verbose I get these: Mesa: User error: GL_INVALID_OPERATION in glProgramStringARB(invalid ARB fragment program option) Mesa: 19 similar GL_INVALID_OPERATION errors Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_VALUE in glDrawBuffersARB(n) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) unsupported texture format in setup_hardware_state failed to validate texture for unit 0. Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_VALUE in glDrawBuffersARB(n) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) unsupported texture format in setup_hardware_state failed to validate texture for unit 0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32449] New: crash in r600_set_vertex_buffers with invalid GL usage flag used in glBufferData
https://bugs.freedesktop.org/show_bug.cgi?id=32449 Summary: crash in r600_set_vertex_buffers with invalid GL usage flag used in glBufferData Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@middleditch.us Created an attachment (id=41180) --> (https://bugs.freedesktop.org/attachment.cgi?id=41180) VBO flag test case If an invalid usage flag (something other than the GL_STATIC_DRAW, GL_DYNAMIC_DRAW, etc.) is passed to glBufferData, then any Draw calls using that VBO will crash inside the r600 driver. The error should either be detected during the call to glBufferData or an invalid flag should simply use a sensible default rather than crashing during Draw. This is on an x86-64 machine (Fedora Rawhide). I do not know if this happens on other architectures. Attaching a simple test case (using GLEW and GLUT). Backtrace from test case is here. I also don't know if this happens with other DRI drivers, and whether this is a bug in the R600 specifically or something that should be fixed higher up in the common Mesa layers, but since the crash happens in the R600 driver I'm assuming that's the culprit. Program received signal SIGSEGV, Segmentation fault. 0x7724dd7f in r600_set_vertex_buffers (ctx=0x6154c0, count=1, buffers=0x7fffd5c0) at r600_state_common.c:165 165if (r600_buffer_is_user_buffer(buffers[i].buffer)) #0 0x7724dd7f in r600_set_vertex_buffers (ctx=0x6154c0, count=1, buffers=0x7fffd5c0) at r600_state_common.c:165 #1 0x77304b3c in st_draw_vbo (ctx=0xb48d80, arrays=, prims=0x7fffdb60, nr_prims=1, ib=0x0, index_bounds_valid=, min_index=0, max_index=2) at state_tracker/st_draw.c:701 #2 0x773012cb in vbo_draw_arrays (ctx=0xb48d80, mode=4, start=0, count=, numInstances=) at vbo/vbo_exec_array.c:588 #3 0x00400d85 in display () #4 0x0039f0020f75 in ?? () from /usr/lib64/libglut.so.3 #5 0x0039f0024ab9 in fgEnumWindows () from /usr/lib64/libglut.so.3 #6 0x0039f00214da in glutMainLoopEvent () from /usr/lib64/libglut.so.3 #7 0x0039f0021db5 in glutMainLoop () from /usr/lib64/libglut.so.3 #8 0x00400f00 in main () -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30483] r600g makes kwin (ab)use 100% CPU
https://bugs.freedesktop.org/show_bug.cgi?id=30483 Øyvind Sæther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:4045
Hi, my OS is a Debian testing with self compiled 2.6.36.1 vanilla kernel. CPU is "model name : Intel(R) Core(TM) i5 CPU 661 @ 3.33GHz" which contains the graphic chip and motherboard is an intel DH55HC. digest of boot log: [ 31.334582] [drm] Initialized drm 1.1.0 20060810 [ 31.347415] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 31.347420] i915 :00:02.0: setting latency timer to 64 [ 31.377104] i915 :00:02.0: irq 43 for MSI/MSI-X [ 31.377113] [drm] set up 31M of stolen space [ 32.100419] fb0: inteldrmfb frame buffer device [ 32.100421] drm: registered panic notifier [ 32.101007] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 $ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 41 2 2 2 IO-APIC-edge timer 1: 1078 1054 1007 1066 IO-APIC-edge i8042 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 4753 4806 4909 4787 IO-APIC-fasteoi ehci_hcd:usb1 17: 0 0 1 0 IO-APIC-fasteoi 23: 8 7 8 7 IO-APIC-fasteoi ehci_hcd:usb2 40: 563021 563010 562925 563092 PCI-MSI-edge eth0 41: 10340 10333 10243 10292 PCI-MSI-edge ahci 42: 17729 17816 17629 17817 PCI-MSI-edge hda_intel 43: 54557 54442 54760 54398 PCI-MSI-edge i915 NMI: 0 0 0 0 Non-maskable interrupts LOC: 423429 423651 430418 434414 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 102315 106505 109466 106257 Rescheduling interrupts CAL: 15015 5403 14241 4556 Function call interrupts TLB: 1068743685 1268 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 8 8 8 8 Machine check polls ERR: 3 MIS: 0 $ cat mtrr reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c000 ( 3072MB), size= 128MB, count=1: write-back reg03: base=0x0c800 ( 3200MB), size= 64MB, count=1: write-back reg04: base=0x1 ( 4096MB), size= 512MB, count=1: write-back reg05: base=0x12000 ( 4608MB), size= 128MB, count=1: write-back reg06: base=0x0d000 ( 3328MB), size= 256MB, count=1: write-combining digest of lspci -v -n 00:02.0 0300: 8086:0042 (rev 02) (prog-if 00 [VGA controller]) Subsystem: 8086:0036 Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at fe00 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at f100 [size=8] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 I switched to another user in X, opened a flash video and switched back to the screen of the first user. The screen kept blank and dmesg shows the following digest: [129031.110919] [ cut here ] [129031.110952] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:4045! [129031.110986] invalid opcode: [#1] SMP [129031.111012] last sysfs file: /sys/devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sdb/uevent [129031.111059] CPU 1 [129031.111071] Modules linked in: cbc aesni_intel cryptd aes_x86_64 aes_generic ecb dm_snapshot ecryptfs i915 drm_kms_helper drm i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect ip6table_filter ip6_tables iptable_filter ip_tables x_tables acpi_cpufreq mperf cpufreq_stats cpufreq_conservative cpufreq_userspace cpufreq_powersave kvm_intel kvm binfmt_misc fuse nls_utf8 bridge stp llc ipv6 reiserfs ext2 loop msr w83627ehf hwmon_vid cifs dm_crypt snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd evdev video output button soundcore snd_page_alloc processor ext4 mbcache jbd2 crc16 usbhid hid dm_mirror dm_region_hash dm_log dm_mod sd_mod ahci libahci libata ehci_hcd scsi_mod e1000e thermal thermal_sys [last unloaded: scsi
Re: [PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote: > On Monday 06 December 2010, David Sin wrote: > > Tiling and Isometric Lightweight Engine for Rotation (TILER) driver > > = > > > > Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. > > Within the DMM exists at least one TILER hardware component. Its purpose > > is to > > organize video/image memory in a 2-dimensional fashion to limit memory > > bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver > > facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the > > TILER container(s). It also facilitates rotating and mirroring the > > allocated > > blocks or its rectangular subsections. > > How does this relate to DRM/GEM? I don't understand too much about graphics > drivers, but it does sound like there is some overlap in functionality. > > I guess at the very least the DMM should live in drivers/gpu/ instead of > drivers/misc, but perhaps it could be integrated more closely with the > existing code there. > > Arnd Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) for x86? I'm trying to understand the differences and make a case that it's not the same as DMM/TILER. thanks, -- David Sin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 11:25:31AM -0600, David Sin wrote: > On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote: > > On Monday 06 December 2010, David Sin wrote: > > > Tiling and Isometric Lightweight Engine for Rotation (TILER) driver > > > = > > > > > > Dynamic Memory Manager (DMM) is a hardware block made by Texas > > > Instruments. > > > Within the DMM exists at least one TILER hardware component. Its purpose > > > is to > > > organize video/image memory in a 2-dimensional fashion to limit memory > > > bandwidth and facilitate 0 effort rotation and mirroring. The TILER > > > driver > > > facilitates allocating, freeing, as well as mapping 2D blocks (areas) in > > > the > > > TILER container(s). It also facilitates rotating and mirroring the > > > allocated > > > blocks or its rectangular subsections. > > > > How does this relate to DRM/GEM? I don't understand too much about graphics > > drivers, but it does sound like there is some overlap in functionality. > > > > I guess at the very least the DMM should live in drivers/gpu/ instead of > > drivers/misc, but perhaps it could be integrated more closely with the > > existing code there. > > > > Arnd > Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) > for x86? I'm trying to understand the differences and make a case that > it's not the same as DMM/TILER. > > thanks, > -- > David Sin Hi Arnd, I'm not sure exactly how DRM/GEM works.. What functionality do you think is overlapping? The main feature, aside from reduced page accesses, of the DMM hw block is to provide physically contiguous 2 dimensional memory blocks for image and video processing. This hw sits between the interconnect and the ext memory interface in the OMAP, and contains an MMU-like address traslator for "virtually" physically contiguous memory and sdram pages. thank you for your comments. BR, -- David Sin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/10] MCDE: Add build files and bus
On 11/26/2010 12:24 PM, Arnd Bergmann wrote: [dri people: please have a look at the KMS discussion way below] On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote: -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: den 25 november 2010 17:48 To: Marcus LORENTZON Cc: linux-arm-ker...@lists.infradead.org; Jimmy RUBIN; linux- me...@vger.kernel.org; Dan JOHANSSON; Linus WALLEIJ Subject: Re: [PATCH 09/10] MCDE: Add build files and bus On Thursday 25 November 2010, Marcus LORENTZON wrote: From: Arnd Bergmann [mailto:a...@arndb.de] On Wednesday 10 November 2010, Jimmy Rubin wrote: This patch adds support for the MCDE, Memory-to-display controller, found in the ST-Ericsson ux500 products. [note: please configure your email client properly so it keeps proper attribution of text and and does not rewrap the citations incorrectly. Wrap your own text after 70 characters] I'm now using Thunderbird, please let me know if it's better than my previous webmail client, neither have many features for reply formatting. All devices that you cannot probe by asking hardware or firmware are normally considered platform devices. Then again, a platform device is usally identified by its resources, i.e. MMIO addresses and interrupts, which I guess your display does not have. Then we might be on right track to model them as devices on a platform bus. Since most displays/panels can't be "plug-n-play" probed, instead devices has to be statically declared in board-xx.c files in mach-ux500 folder. Or is platform bus a "singleton"? Or can we define a new platform bus device? Displays like HDMI TV-sets are not considered for device/driver in mcde. Instead there will be a hdmi-chip-device/driver on the mcde bus. So all devices and drivers on this bus are static. I think I need to clarify to things: * When I talk about a bus, I mean 'struct bus_type', which identifies all devices with a uniform bus interface to their parent device (think: PCI, USB, I2C). You seem to think of a bus as a specific instance of that bus type, i.e. the device that is the parent of all the connected devices. If you have only one instance of a bus in any system, and they are all using the same driver, do not add a bus_type for it. A good reason to add a bus_type would be e.g. if the "display" driver uses interfaces to the dss that are common among multiple dss drivers from different vendors, but the actual display drivers are identical. This does not seem to be the case. Correct, I refer to the device, not type or driver. I used a bus type since it allowed me to setup a default implementation for each driver callback. So all drivers get generic implementation by default, and override when that is not enough. Meybe you have a better way of getting the same behavior. * When you say that the devices are static, I hope you do not mean static in the C language sense. We used to allow devices to be declared as "static struct" and registered using platform_device_register (or other bus specific functions). This is no longer valid and we are removing the existing users, do not add new ones. When creating a platform device, use platform_device_register_simple or platform_device_register_resndata. I'm not sure what you mean with drivers being static. Predefining the association between displays and drivers in per-machine files is fine, but since this is really board specific, it would be better to eventually do this through data passed from the boot loader, so you don't have to have a machine file for every combination of displays that is in the field. I guess you have read the ARM vs static platform_devices. But, yes, I mean in the c-language static sense. I will adopt to whatever Russel King says is The right way in ARM SoCs. Staging it in a way that adds all the display drivers later than the base driver is a good idea, but it would be helpful to also add the infrastructure at the later stage. Maybe you can try to simplify the code for now by hardcoding the single display and remove the dynamic registration. You still have the the code, so once the base code looks good for inclusion, we can talk about it in the context of adding dynamic display support back in, possibly in exactly the way you are proposing now, but perhaps in an entirely different way if we come up with a better solution. What about starting with MCDE HW, which is the core HW driver doing all real work? And then continue with the infrastructure + some displays + drivers ... This is already the order in which you submitted them, I don't see a difference here. I was not asking to delay any of the code, just to put them in a logical order. We are now taking a step back and start "all over". We were almost as fresh on this HW block as you are now when we started implementing the driver earlier th
Re: [PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote: > As far as I can tell, both DMM and GEM at a high level manage objects > in video memory. The IOMMU that you have on the Omap hardware seems > to resemble the GART that sits between PC-style video cards and main > memory. > > I don't know any details, but google quickly finds > http://lwn.net/Articles/283798/ with a description of the > initial GEM design. My main thought when looking over the > DMM code was that this should not be tied too closely to a > specific hardware, and GEM seems to be an existing abstraction > that may fit what you need. > > Arnd Thanks for the pointer, Arnd. I also found a nice readme file in the gpu/drm directory, which points to a wiki and source code. I'll read into this and get back to you. BR, -- David Sin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc6
On Thu, 16 Dec 2010 18:30:11 +0100, Domenico Andreoli wrote: > Hi, > > On Wed, Dec 15, 2010 at 07:10:28PM -0800, ext Linus Torvalds wrote: > > > > Go forth and test. And please do remember to ping bugzilla (or > > developers) about any regressions you find, whether new or old. > > I have some problem with i945, display remains blank. I also tried > adding i915.modeset=0 but nothing changed. Machine is well alive and > responds to basic commands like Ctrl+Alt+F1 and Ctrl+Alt+Del but I have > not other machine to enter via network. If i915.modeset=0 doesn't restore the display then something is extremely fishy. Do you see any console output before the i915.ko is loaded? > [1.284262] [drm] Initialized drm 1.1.0 20060810 > [1.284334] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > [1.485212] vgaarb: device changed decodes: > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > [1.485642] [drm] initialized overlay support > [2.526011] No connectors reported connected with modes > [2.526053] [drm] Cannot find any crtc or sizes - going 1024x768 The issue appears to be that no outputs are being detected. I presume that you have instead a VGA connected to the box and that the regression is in fact e7dbb2f2. If I'm guessing rightly: diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 8df5743..14c276e 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -148,7 +148,9 @@ static void intel_crt_mode_set(struct drm_encoder *encoder, dpll_md & ~DPLL_MD_UDI_MULTIPLIER_MASK); } - adpa = ADPA_HOTPLUG_BITS; + adpa = 0; + if (INTEL_INFO(dev)->gen >= 4) + adpa |= ADPA_HOTPLUG_BITS; if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC) adpa |= ADPA_HSYNC_ACTIVE_HIGH; if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC) -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: i915 causes NULL pointer dereference in 2.6.37-rc5-git4
On środa, 15 grudnia 2010 o 11:48:21 Tõnu Raitviir wrote: > Asus P5E-VM HDMI motherboard with G35 chipset, only HDMI output is > connected. Last known good kernel was 2.6.36.2 > > 00:02.0 VGA compatible controller: Intel Corporation 82G35 Express > Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel > Corporation 82G35 Express Integrated Graphics Controller (rev 03) I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=25012 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.maciek.unixy.pl ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32455] New: Crash with mame using OpenGL with newest Gallium on Radeon 4350
https://bugs.freedesktop.org/show_bug.cgi?id=32455 Summary: Crash with mame using OpenGL with newest Gallium on Radeon 4350 Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: bitbyte...@gmail.com This is a backtrace of the issue, seems the first buffer is 0x0 and crashing on that in the r600g Gallium driver. This is running the newest Mame using OpenGL, Linux-Next, everything basically from GIT and newest up to date code. I suspect something in Mame might be causing the first buffer to be NULL, but not sure and it works on Classic so something is different in Gallium I am guessing. arcade mesa # lspci -v -s 01:00.0 01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (prog-if 00 [VGA controller]) Subsystem: Diamond Multimedia Systems Device 4350 Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at c8b0 (64-bit, non-prefetchable) [size=64K] I/O ports at 2000 [size=256] [virtual] Expansion ROM at e01e [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information Kernel driver in use: radeon Kernel modules: radeon Linux arcade 2.6.37-rc5-next-20101213 #1 SMP Tue Dec 14 18:23:46 CST 2010 i686 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux (gdb) run pacman -verbose Starting program: /mnt/livecd/usr/games/bin/mame pacman -verbose [Thread debugging using libthread_db enabled] Parsing mame.ini [New Thread 0xb6f4db70 (LWP 25175)] Build version: 0.140u2 (Dec 16 2010) Build architecure: SDLMAME_ARCH= Build defines 1:SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1 Build defines 1:LSB_FIRST=1 MAME_DEBUG=1 DISTRO=generic SYNC_IMPLEMENTATION=tc SDL/OpenGL defines: SDL_COMPILEDVERSION=1214 USE_OPENGL=1 USE_DISPATCH_GL=1 Compiler defines A: __GNUC__=4 __GNUC_MINOR__=4 __GNUC_PATCHLEVEL__=4 __VERSION__="4.4.4" Compiler defines B: __unix__=1 __i386__=1 Compiler defines C: __USE_FORTIFY_LEVEL=0 SDL Device Driver : x11 SDL Monitor Dimensions: 648 x 480 Enter sdlwindow_init Using SDL single-window OpenGL driver (SDL 1.2) Leave sdlwindow_init 648x 480 -> 0.001621 Loaded opengl shared library: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable OpenGL: X.Org OpenGL: Gallium 0.4 on AMD RV710 OpenGL: 2.1 Mesa 7.10-devel OpenGL: texture rectangle supported OpenGL: non-power-of-2 textures supported (new method) OpenGL: vertex buffer supported OpenGL: pixel buffers supported OpenGL: framebuffer object supported OpenGL: GLSL supported, but disabled OpenGL: max texture size 8192 x 8192 Keyboard: Start initialization Input: Adding Kbd #1: System keyboard Keyboard: Registered System keyboard Keyboard: End initialization Mouse: Start initialization Input: Adding Mouse #1: System mouse Mouse: Registered System mouse Mouse: End initialization Joystick: Start initialization Joystick: End initialization Audio: Start initialization Audio: Driver is alsa [New Thread 0xb565eb70 (LWP 25176)] Audio: frequency: 48000, channels: 2, samples: 1024 sdl_create_buffers: creating stream buffer of 57344 bytes Audio: End initialization ouput: unable to open output notifier file /tmp/sdlmame_out Input: Changing default joystick map = s8.4s8.44s8.4445 s888s 4s8s6 44s888s66 444555666 444555666 444555666 44s222s66 4s2s6 s222s Input: Changing default joystick map = s8.4s8.44s8.4445 s888s 4s8s6 44s888s66 444555666 444555666 444555666 44s222s66 4s2s6 s222s Matching font: /usr/share/fonts/liberation-fonts/LiberationSans-Regular.ttf 648x 480 -> 0.001621 Starting Driver Device 'root' (missing dependencies; rescheduling) Starting Z80 'maincpu' Starting Video Screen 'screen' Starting Speaker 'mono' (missing dependencies; rescheduling) Starting Namco 'namco' Starting Driver Device 'root' (missing dependencies; rescheduling) Starting Speaker 'mono' Starting Driver Device 'root' OpenGL: VBO supported OpenGL: PBO supported OpenGL: FBO supported OpenGL: using vid filter: 0 GL texture: copy 1, shader 0, dynamic 1, 288x224 288x224 [PALETTE16, Equal: 0, Palette: 1, scale 1x1, border 0, pitch 384,288/8192], colors: 512, bytes/pix 4 Program received signal SIGSEGV, Segmentation fault. 0xb5c01eec in r600_buffer_is_user_buffer (buffer=0x0) at r600_resource.h:103 103r600_resource.h: No such file or directory. in r600_resource.h (gdb) backtrace #0 0xb5c01eec in r600_buffer_is_user_buffer (buffer=0x0) at r600_resource.h:
[Bug 32456] New: r600g makes sdlmame SIGSEGV, r600_set_vertex_buffers involvement indicated
https://bugs.freedesktop.org/show_bug.cgi?id=32456 Summary: r600g makes sdlmame SIGSEGV, r600_set_vertex_buffers involvement indicated Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: low Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: oyvi...@everdot.org 1. run sdlmame. 2. it dies on SIGSEGV, Segmentation fault. gdb sdlmame (gdb) run -video opengl -rompath /public/net/godzilla/games/MAME/roms/ mslug2 Starting program: /usr/games/bin/sdlmame -video opengl -rompath /public/net/godzilla/games/MAME/roms/ mslug2 [Thread debugging using libthread_db enabled] Warning: unknown option in INI: useallheads Warning: unknown option in INI: useallheads [New Thread 0x7427e710 (LWP 29182)] [New Thread 0x704e9710 (LWP 29183)] WARNING: Couldn't find/open TrueType font Liberation Sans, using MAME default Program received signal SIGSEGV, Segmentation fault. 0x72188339 in r600_set_vertex_buffers () from /usr/lib64/dri/r600_dri.so (gdb) bt #0 0x72188339 in r600_set_vertex_buffers () from /usr/lib64/dri/r600_dri.so #1 0x7223959c in st_draw_vbo () from /usr/lib64/dri/r600_dri.so #2 0x722362a3 in vbo_draw_arrays () from /usr/lib64/dri/r600_dri.so #3 0x00ff96f9 in drawogl_window_draw(_sdl_window_info*, unsigned int, int) () #4 0x00ff1cc6 in draw_video_contents_wt(void*, int) () #5 0x00ff2fc6 in sdlwindow_video_window_update(running_machine*, _sdl_window_info*) () #6 0x00fd39ac in sdl_osd_interface::update(bool) () #7 0x016206c4 in video_manager::frame_update(bool) () #8 0x015ebd47 in display_loading_rom_message(_romload_private*, char const*) () #9 0x015ecf9f in process_rom_entries(_romload_private*, char const*, rom_entry const*) () #10 0x015edf17 in rom_init(running_machine*) () #11 0x01597b02 in running_machine::start() () #12 0x0159803b in running_machine::run(bool) () #13 0x015963d0 in mame_execute(osd_interface&, _core_options*) () #14 0x0154fbe5 in cli_execute(int, char**, osd_interface&, _options_entry const*) () #15 0x00fd03bf in main () (gdb) quit -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Álmos changed:
What|Removed |Added
Attachment #41170|0 |1
is obsolete||
--- Comment #22 from Álmos 2010-12-16 15:18:11 PST ---
Created an attachment (id=41192)
View: https://bugs.freedesktop.org/attachment.cgi?id=41192
Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41192
r300g_multitexturing_v2.diff
Yes, your calculations are OK. The problem is the
if (&state->sampler_views[i]->base != views[i]) {}
part, which leaves some samplers untouched, and their cache regions get reused
sometimes.
My attached patch is IMHO significantly better than the previous one. It
completely fixes texturing in etqw, but there are occasional glitches in ut2004
and the water in googleearth is still bad. See the TODO and XXX comments in the
patch for more explanation.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix DCE4.1 dig routing
Works just like DCE4.0 despite what the docs say.
This fixes blank screen issues when changing crtc
routing due to incorrect crtc to dig mapping.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 17 +++--
1 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index e4e64a8..10ba103 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -910,15 +910,9 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
else
args.v3.ucLaneNum = 4;
- if (ASIC_IS_DCE41(rdev)) {
- args.v3.acConfig.ucEncoderSel = dig->dig_encoder;
- if (dig->linkb)
- args.v3.acConfig.ucLinkSel = 1;
- } else {
- if (dig->linkb) {
- args.v3.acConfig.ucLinkSel = 1;
- args.v3.acConfig.ucEncoderSel = 1;
- }
+ if (dig->linkb) {
+ args.v3.acConfig.ucLinkSel = 1;
+ args.v3.acConfig.ucEncoderSel = 1;
}
/* Select the PLL for the PHY
@@ -1535,11 +1529,6 @@ static int radeon_atom_pick_dig_encoder(struct
drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig;
uint32_t dig_enc_in_use = 0;
- /* on DCE41 and encoder can driver any phy so just crtc id */
- if (ASIC_IS_DCE41(rdev)) {
- return radeon_crtc->crtc_id;
- }
-
if (ASIC_IS_DCE4(rdev)) {
dig = radeon_encoder->enc_priv;
switch (radeon_encoder->encoder_id) {
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] TI DMM-TILER driver
On Fri, Dec 17, 2010 at 5:02 AM, David Sin wrote: > On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote: >> As far as I can tell, both DMM and GEM at a high level manage objects >> in video memory. The IOMMU that you have on the Omap hardware seems >> to resemble the GART that sits between PC-style video cards and main >> memory. >> >> I don't know any details, but google quickly finds >> http://lwn.net/Articles/283798/ with a description of the >> initial GEM design. My main thought when looking over the >> DMM code was that this should not be tied too closely to a >> specific hardware, and GEM seems to be an existing abstraction >> that may fit what you need. >> >> Arnd > Thanks for the pointer, Arnd. I also found a nice readme file in > the gpu/drm directory, which points to a wiki and source code. > I'll read into this and get back to you. I get the impression with the ARM graphics, that you just have a lot of separate drivers for separate IP blocks all providing some misc random interfaces to userspace where some binary driver binds all the functionality together into a useful whole, which seems like a really bad design. Generally on x86, the tiling hw is part of the GPU and is exposed as part of a coherent GPU driver. I'm just wonder what the use-cases for this tiler are and what open apps can use it for? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix DCE4.1 dig routing (v2)
Works more like DCE4.0 despite what the docs say.
This fixes blank screen issues when changing crtc
routing due to incorrect crtc to dig mapping.
v2: only two DIGx blocks, routing is hardcoded
based on link.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 54 ++
1 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index e4e64a8..55b84b8 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -910,15 +910,9 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
else
args.v3.ucLaneNum = 4;
- if (ASIC_IS_DCE41(rdev)) {
- args.v3.acConfig.ucEncoderSel = dig->dig_encoder;
- if (dig->linkb)
- args.v3.acConfig.ucLinkSel = 1;
- } else {
- if (dig->linkb) {
- args.v3.acConfig.ucLinkSel = 1;
- args.v3.acConfig.ucEncoderSel = 1;
- }
+ if (dig->linkb) {
+ args.v3.acConfig.ucLinkSel = 1;
+ args.v3.acConfig.ucEncoderSel = 1;
}
/* Select the PLL for the PHY
@@ -1535,32 +1529,34 @@ static int radeon_atom_pick_dig_encoder(struct
drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig;
uint32_t dig_enc_in_use = 0;
- /* on DCE41 and encoder can driver any phy so just crtc id */
- if (ASIC_IS_DCE41(rdev)) {
- return radeon_crtc->crtc_id;
- }
-
if (ASIC_IS_DCE4(rdev)) {
dig = radeon_encoder->enc_priv;
- switch (radeon_encoder->encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ if (ASIC_IS_DCE41(rdev)) {
if (dig->linkb)
return 1;
else
return 0;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- if (dig->linkb)
- return 3;
- else
- return 2;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- if (dig->linkb)
- return 5;
- else
- return 4;
- break;
+ } else {
+ switch (radeon_encoder->encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ if (dig->linkb)
+ return 1;
+ else
+ return 0;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ if (dig->linkb)
+ return 3;
+ else
+ return 2;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ if (dig->linkb)
+ return 5;
+ else
+ return 4;
+ break;
+ }
}
}
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #23 from Chris Rankin 2010-12-16 16:37:34 PST --- (In reply to comment #22) > My attached patch is IMHO significantly better than the previous one. The patch may be flawed, but it greatly improves WoW as well. I've just run around a couple of "texture hotspots" without noticing any problems, although the console log has been warning me of "trouble ahead" a fair bit as well. I would say that the patch is definitely heading in the correct general direction. (Although it doesn't apply cleanly to git. Perhaps it was made against altered sources?) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24462] r600: spread spectrum: flickering screen (bisected)
https://bugzilla.kernel.org/show_bug.cgi?id=24462 Florian Mickler changed: What|Removed |Added Status|NEW |RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #10 from Florian Mickler 2010-12-17 00:43:13 --- Patch: https://bugzilla.kernel.org/attachment.cgi?id=39372 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24382] 2.6.37-rc4: kdm crashes consistently, 2.6.36 not affected, drm:radeon_cs_ioctl Invalid command stream
https://bugzilla.kernel.org/show_bug.cgi?id=24382 Florian Mickler changed: What|Removed |Added Status|NEW |RESOLVED CC||flor...@mickler.org Resolution||CODE_FIX --- Comment #2 from Florian Mickler 2010-12-17 00:44:22 --- Please shout, if that is not the case. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24382] 2.6.37-rc4: kdm crashes consistently, 2.6.36 not affected, drm:radeon_cs_ioctl Invalid command stream
https://bugzilla.kernel.org/show_bug.cgi?id=24382 Florian Mickler changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 22472] vga_switcheroo fails to switch from intel to ati
https://bugzilla.kernel.org/show_bug.cgi?id=22472 --- Comment #13 from Florian Mickler 2010-12-17 01:17:14 --- Did you find anything useful? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] vgaarb: use bridges to control VGA routing where possible.
From: Dave Airlie
So in a lot of modern systems, a GPU will always be below a parent bridge that
won't share with any other GPUs. This means VGA arbitration on those GPUs can
be controlled by using the bridge routing instead of io/mem decodes.
The problem is locating which GPUs share which upstream bridges. This patch
attempts to identify all the GPUs which can be controlled via bridges, and ones
that can't. This patch endeavours to work out the bridge sharing semantics.
When disabling GPUs via a bridge, it doesn't do irq callbacks or touch the
io/mem decodes for the gpu.
Signed-off-by: Dave Airlie
---
drivers/gpu/vga/vgaarb.c | 113 --
drivers/pci/pci.c| 25 ++-
include/linux/pci.h |7 ++-
3 files changed, 118 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index c380c65..aab5c59 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -61,7 +61,7 @@ struct vga_device {
unsigned int mem_lock_cnt; /* legacy MEM lock count */
unsigned int io_norm_cnt; /* normal IO count */
unsigned int mem_norm_cnt; /* normal MEM count */
-
+ bool bridge_has_one_vga;
/* allow IRQ enable/disable hook */
void *cookie;
void (*irq_set_state)(void *cookie, bool enable);
@@ -165,6 +165,8 @@ static struct vga_device *__vga_tryget(struct vga_device
*vgadev,
unsigned int wants, legacy_wants, match;
struct vga_device *conflict;
unsigned int pci_bits;
+ u32 flags = 0;
+
/* Account for "normal" resources to lock. If we decode the legacy,
* counterpart, we need to request it as well
*/
@@ -237,16 +239,23 @@ static struct vga_device *__vga_tryget(struct vga_device
*vgadev,
/* looks like he doesn't have a lock, we can steal
* them from him
*/
- vga_irq_set_state(conflict, false);
+ flags = 0;
pci_bits = 0;
- if (lwants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
- pci_bits |= PCI_COMMAND_MEMORY;
- if (lwants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
- pci_bits |= PCI_COMMAND_IO;
- pci_set_vga_state(conflict->pdev, false, pci_bits,
- change_bridge);
+ if (!conflict->bridge_has_one_vga) {
+ vga_irq_set_state(conflict, false);
+ flags |= PCI_VGA_STATE_CHANGE_DECODES;
+ if (lwants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+ pci_bits |= PCI_COMMAND_MEMORY;
+ if (lwants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+ pci_bits |= PCI_COMMAND_IO;
+ }
+
+ if (change_bridge)
+ flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+
+ pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
conflict->owns &= ~lwants;
/* If he also owned non-legacy, that is no longer the case */
if (lwants & VGA_RSRC_LEGACY_MEM)
@@ -261,14 +270,24 @@ enable_them:
* also have in "decodes". We can lock resources we don't decode but
* not own them.
*/
+ flags = 0;
pci_bits = 0;
- if (wants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
- pci_bits |= PCI_COMMAND_MEMORY;
- if (wants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
- pci_bits |= PCI_COMMAND_IO;
- pci_set_vga_state(vgadev->pdev, true, pci_bits, !!(wants &
VGA_RSRC_LEGACY_MASK));
- vga_irq_set_state(vgadev, true);
+ if (!vgadev->bridge_has_one_vga) {
+ flags |= PCI_VGA_STATE_CHANGE_DECODES;
+ if (wants & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+ pci_bits |= PCI_COMMAND_MEMORY;
+ if (wants & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+ pci_bits |= PCI_COMMAND_IO;
+ }
+ if (!!(wants & VGA_RSRC_LEGACY_MASK))
+ flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
+
+ pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);
+
+ if (!vgadev->bridge_has_one_vga) {
+ vga_irq_set_state(vgadev, true);
+ }
vgadev->owns |= (wants & vgadev->decodes);
lock_them:
vgadev->locks |= (rsrc & VGA_RSRC_LEGACY_MASK);
@@ -421,6 +440,62 @@ bail:
}
EXPORT_SYMBOL(vga_put);
+/* Rules for using a bridge to control a VGA descendant decoding:
+ if a bridge has only one VGA descendant then it can be used
+ to control the VGA routing for that device.
+ It should always use the bridge closest to the device to control it.
+ If a bridge has a direct VGA descendant, but also have a sub-bridge
+ VGA descendant then we cannot use that bridge to control the dire
[PATCH] vgaarb: use bridges to control VGA routing where possible.
On 16/12/2010 05:54, Dave Airlie wrote:
> From: Dave Airlie
> int pci_set_vga_state(struct pci_dev *dev, bool decode,
> - unsigned int command_bits, bool change_bridge)
> + unsigned int command_bits, u32 flags)
> {
> struct pci_bus *bus;
> struct pci_dev *bridge;
> u16 cmd;
> int rc;
>
> - WARN_ON(command_bits& ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY));
> + WARN_ON((flags& PCI_VGA_STATE_CHANGE_DECODES)& (command_bits&
> ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
Minor thing, but I think the middle & should be a &&?
MM
[PATCH 0/9] TI DMM-TILER driver
On Monday 06 December 2010, David Sin wrote: > Tiling and Isometric Lightweight Engine for Rotation (TILER) driver > = > > Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. > Within the DMM exists at least one TILER hardware component. Its purpose is > to > organize video/image memory in a 2-dimensional fashion to limit memory > bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver > facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the > TILER container(s). It also facilitates rotating and mirroring the allocated > blocks or its rectangular subsections. How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality. I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there. Arnd
[Bug 32439] New: invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 Summary: invisible objects on r600g (probably shader issue) Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: hramrach at centrum.cz Created an attachment (id=41168) --> (https://bugs.freedesktop.org/attachment.cgi?id=41168) dumped shaders Last time this happened it was due to some shaders failing to compile. Mesa does not report failed shader compilation so I will try to attach all shaders the program compiled. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] vgaarb: use bridges to control VGA routing where possible.
2010/12/16 Mark Marshall :
> On 16/12/2010 05:54, Dave Airlie wrote:
>>
>> From: Dave Airlie
>> ?int pci_set_vga_state(struct pci_dev *dev, bool decode,
>> - ? ? ? ? ? ? ? ? ? ? unsigned int command_bits, bool change_bridge)
>> + ? ? ? ? ? ? ? ? ? ? unsigned int command_bits, u32 flags)
>> ?{
>> ? ? ? ?struct pci_bus *bus;
>> ? ? ? ?struct pci_dev *bridge;
>> ? ? ? ?u16 cmd;
>> ? ? ? ?int rc;
>>
>> - ? ? ? WARN_ON(command_bits& ?~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY));
>> + ? ? ? WARN_ON((flags& ?PCI_VGA_STATE_CHANGE_DECODES)& ?(command_bits&
>> ?~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
>
> Minor thing, but I think the middle & should be a &&?
Dave: as you are going to fix patch, please add spaces around "|" by the way:
PCI_COMMAND_IO|PCI_COMMAND_MEMORY
--
Rafa?
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #20 from ?lmos 2010-12-16 06:12:18 PST --- Created an attachment (id=41170) View: https://bugs.freedesktop.org/attachment.cgi?id=41170 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41170 r300g_multitexturing.diff I played around with the tmu texture cache region assignment code, read the corresponding part of the r3xx register manual, and deduced the following: - you must assign different region for different textures - assigned regions must not overlap The existing code guarantees none of these, especially if there are partial updates (which are quite common). The texture corruption is the result of the tmu loading different textures into the same cache area (possibly in different formats), and only one of them won't be garbage. This only applies to r3xx and r4xx, because r5xx ignores this parameter and assigns cache automatically. My patch doesn't guarantee anything either, is meant to be a proof-of-concept (or more like a hackload of hacky hacks), that almost completely fixes texturing in ut2004, vastly improves the situation in etqw (the corruption occurs only on strogg architecture and vehicles instead of almost everywhere), and changes nothing in googleearth. Doom3 would also be a good test, but it crashes since I increased GART from 64MB to 256MB. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH][next] drm/vmwgfx: Let SVGA_REG_NUM_DISPLAYS decide output connectivity
Makes the user able to determine the number of connected outputs from
the VMware GUI.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 29113c9..335c91c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -340,9 +340,16 @@ static enum drm_connector_status
vmw_ldu_connector_detect(struct drm_connector *connector,
bool force)
{
- if (vmw_connector_to_ldu(connector)->pref_active)
- return connector_status_connected;
- return connector_status_disconnected;
+ uint32_t num_displays;
+ struct drm_device *dev = connector->dev;
+ struct vmw_private *dev_priv = vmw_priv(dev);
+
+ mutex_lock(&dev_priv->hw_mutex);
+ num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS);
+ mutex_unlock(&dev_priv->hw_mutex);
+
+ return ((vmw_connector_to_ldu(connector)->base.unit < num_displays) ?
+ connector_status_connected : connector_status_disconnected);
}
static struct drm_display_mode vmw_ldu_connector_builtin[] = {
--
1.6.2.5
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 --- Comment #1 from Michal Suchanek 2010-12-16 06:30:01 PST --- Can't run the same program on r600c but it works on Mesa 7.9 r300g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 --- Comment #2 from Michal Suchanek 2010-12-16 06:54:21 PST --- Created an attachment (id=41175) --> (https://bugs.freedesktop.org/attachment.cgi?id=41175) difference between r600 shaders and swrastg shaders It works with swrastg and there is diference in size of arrays. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #21 from Marek Ol??k 2010-12-16 07:00:56 PST --- (In reply to comment #20) > Created an attachment (id=41170) View: https://bugs.freedesktop.org/attachment.cgi?id=41170 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41170 > r300g_multitexturing.diff > > I played around with the tmu texture cache region assignment code, read the > corresponding part of the r3xx register manual, and deduced the following: > - you must assign different region for different textures > - assigned regions must not overlap > The existing code guarantees none of these, especially if there are partial > updates (which are quite common). The texture corruption is the result of the > tmu loading different textures into the same cache area (possibly in different > formats), and only one of them won't be garbage. Thanks a lot for looking into this, but let's discuss it a bit. Could you give me a prove that the current code is wrong? At least one case where the assignment of texture cache regions is done wrong. Currently it should assign the regions as follows: 1 texture: R300_TX_CACHE_WHOLE 2 textures: R300_TX_CACHE_HALF_0 R300_TX_CACHE_HALF_1 3 textures: R300_TX_CACHE_HALF_1 R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 4 textures: R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 5 textures: R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 6 textures: R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 7 textures: R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 R300_TX_CACHE_EIGHTH_4 R300_TX_CACHE_EIGHTH_5 8 textures: R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 R300_TX_CACHE_EIGHTH_4 R300_TX_CACHE_EIGHTH_5 R300_TX_CACHE_EIGHTH_6 R300_TX_CACHE_EIGHTH_7 And so on. I can't see any overlapping regions. It always divides the whole texture cache between all the textures. The code assumes each region can be divided to two of half the size of the original one. E.g. the case with 2 textures is: R300_TX_CACHE_HALF_0 R300_TX_CACHE_HALF_1 And when you add the 3rd texture, the first region will get divided evenly like this: R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_HALF_1 Does it look wrong to you? Do you think that the hardware doesn't like so _tight_ configuration of the regions? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24932] BUG: unable to handle kernel paging request
https://bugzilla.kernel.org/show_bug.cgi?id=24932 --- Comment #4 from Lars-Dominik Braun 2010-12-16 15:02:49 --- > Yes please, it would be useful to know if 2.6.35 had the same bug. 2.6.35.9 (vanilla) works fine. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 Michel D?nzer changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32439] invisible objects on r600g (probably shader issue)
https://bugs.freedesktop.org/show_bug.cgi?id=32439 Jerome Glisse changed: What|Removed |Added Attachment #41168|shaders.log |shaders.txt filename|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32422] Large images displayed in Firefox appear corrupted
https://bugs.freedesktop.org/show_bug.cgi?id=32422 --- Comment #8 from Michel D?nzer 2010-12-16 08:40:47 PST --- (In reply to comment #7) > Even with the patch for bug 31708 applied, I see the same corruption in > firefox [...] That's with the latest version (v3) of the patch? (Jerome even submitted v4 later, but I don't think the difference from v3 should be relevant for this problem; wouldn't hurt to try of course) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/9] TI DMM-TILER driver
On Thursday 16 December 2010 18:37:38 David Sin wrote: > I'm not sure exactly how DRM/GEM works.. What functionality do you think is > overlapping? The main feature, aside from reduced page accesses, of the DMM > hw block is to provide physically contiguous 2 dimensional memory blocks for > image and video processing. This hw sits between the interconnect and the > ext memory interface in the OMAP, and contains an MMU-like address traslator > for "virtually" physically contiguous memory and sdram pages. As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory. I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need. Arnd
[Bug 32447] New: GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 Summary: GPU lockup with Braid Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: marti at juffo.org When trying to run the "Braid" game, recently released for Linux as part of the Humble Indie Bundle, I see the game with corrupt graphics, and a segfault crash after a short while. After several such tries, it started locking up the GPU. I'm using Radeon HD 4870 (RV770) on 64-bit Arch Linux. The game is 32-bit. In order to run this game in the first place, I had to set force_s3tc_enable in drirc and install the libtxc_dxtn library. Versions: kernel 2.6.36.2 xorg-server 1.9.2 ati-dri 7.9.0.git20101207 mesa 7.9.0.git20101207 xf86-video-ati 6.13.2 glproto 1.4.12 At first when I run it I get: % gdb --args ./braid -windowed (gdb) run unsupported texture format in setup_hardware_state failed to validate texture for unit 0. ... ^ repeats lots of times Program received signal SIGSEGV, Segmentation fault. 0xf63e40ed in radeonEmitVec4 () from /usr/lib32/xorg/modules/dri/r600_dri.so (gdb) bt #0 0xf63e40ed in radeonEmitVec4 () from /usr/lib32/xorg/modules/dri/r600_dri.so #1 0xf63c1fbe in r700DrawPrims () from /usr/lib32/xorg/modules/dri/r600_dri.so #2 0xf64ab187 in vbo_exec_DrawArrays () from /usr/lib32/xorg/modules/dri/r600_dri.so #3 0xf64a1797 in neutral_DrawArrays () from /usr/lib32/xorg/modules/dri/r600_dri.so #4 0x081974cb in Display_System_OGL::immediate_flush() () #5 0x080cdfd1 in draw_intro_notification(float, char*, char*) () #6 0x080cf9e4 in draw_overlays_for_gameplay() () #7 0x080d0c2a in draw_world_view() () #8 0x080eaed1 in draw_game_mode() () #9 0x080eda1e in app_main(int, char**) () #10 0x0815223e in main () After a few tries, I start getting these GPU lockups, which turn my screen into a garbled mess. After a while the desktop environment re-appears, but then crashes again and finally suspends both my screens. I can switch to a VT terminal and 'kill -9 braid'. When switching back to Xorg, everything is back to normal. :) Here's from dmesg: radeon :01:00.0: GPU lockup CP stall for more than 1msec radeon :01:00.0: GPU lockup CP stall for more than 1msec [ cut here ] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x376/0x3e0 [radeon]() Hardware name: System Product Name GPU lockup (waiting for 0x0001D61D last fence id 0x0001D61C) Modules linked in: fuse ip6table_filter ip6_tables xt_CHECKSUM bridge stp llc hwmon_vid cpufreq_ondemand sit tunnel4 iptable_mangle xt_state ipt_REJECT xt_NFQUEUE iptable_filter ipt_REDIRECT xt_tcpudp ipt_MASQUERADE xt_owner iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables btrfs zlib_deflate crc32c libcrc32c usbhid hid snd_hda_codec_atihdmi usb_storage snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_via radeon snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd ttm soundcore snd_page_alloc drm_kms_helper drm i2c_piix4 i2c_algo_bit i2c_core ohci_hcd dm_mod ehci_hcd edac_core edac_mce_amd evdev sg asus_atk0110 parport_pc usbcore ppdev button thermal psmouse wmi serio_raw shpchp pci_hotplug k10temp lp parport kvm_amd kvm r8169 mii powernow_k8 freq_table processor mperf ipv6 autofs4 ext4 mbcache jbd2 crc16 sr_mod cdrom floppy pata_atiixp pata_acpi sd_mod ahci libahci libata scsi_mod Pid: 3274, comm: X Not tainted 2.6.36-ARCH #1 [ cut here ] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x376/0x3e0 [radeon]() Hardware name: System Product Name GPU lockup (waiting for 0x0001D61F last fence id 0x0001D61C) Modules linked in: fuse ip6table_filter ip6_tables xt_CHECKSUM bridge stp llc hwmon_vid cpufreq_ondemand sit tunnel4 iptable_mangle xt_state ipt_REJECT xt_NFQUEUE iptable_filter ipt_REDIRECT xt_tcpudp ipt_MASQUERADE xt_owner iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables btrfs zlib_deflate crc32c libcrc32c usbhid hid snd_hda_codec_atihdmi usb_storage snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_via radeon snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd ttm soundcore snd_page_alloc drm_kms_helper drm i2c_piix4 i2c_algo_bit i2c_core ohci_hcd dm_mod ehci_hcd edac_core edac_mce_amd evdev sg asus_atk0110 parport_pc usbcore ppdev button thermal psmouse wmi serio_raw shpchp pci_hotplug k10temp lp parport kvm_amd kvm r8169 mii powernow_k8 freq_table processor mperf ipv6 autofs4 ext4 mbcache jbd2 crc16 sr_mod cdrom floppy pata_atiixp pata_acpi sd_mod ahci libahci libata scsi_mod Pid: 3830, comm: braid Not t
[Bug 32447] GPU lockup with Braid
https://bugs.freedesktop.org/show_bug.cgi?id=32447 --- Comment #1 from Marti 2010-12-16 10:30:25 PST --- Another data point, when running with MESA_DEBUG=verbose I get these: Mesa: User error: GL_INVALID_OPERATION in glProgramStringARB(invalid ARB fragment program option) Mesa: 19 similar GL_INVALID_OPERATION errors Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_VALUE in glDrawBuffersARB(n) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) unsupported texture format in setup_hardware_state failed to validate texture for unit 0. Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) Mesa: User error: GL_INVALID_VALUE in glDrawBuffersARB(n) Mesa: User error: GL_INVALID_ENUM in glFramebufferTexture2DEXT(attachment) unsupported texture format in setup_hardware_state failed to validate texture for unit 0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32449] New: crash in r600_set_vertex_buffers with invalid GL usage flag used in glBufferData
https://bugs.freedesktop.org/show_bug.cgi?id=32449 Summary: crash in r600_set_vertex_buffers with invalid GL usage flag used in glBufferData Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sean at middleditch.us Created an attachment (id=41180) --> (https://bugs.freedesktop.org/attachment.cgi?id=41180) VBO flag test case If an invalid usage flag (something other than the GL_STATIC_DRAW, GL_DYNAMIC_DRAW, etc.) is passed to glBufferData, then any Draw calls using that VBO will crash inside the r600 driver. The error should either be detected during the call to glBufferData or an invalid flag should simply use a sensible default rather than crashing during Draw. This is on an x86-64 machine (Fedora Rawhide). I do not know if this happens on other architectures. Attaching a simple test case (using GLEW and GLUT). Backtrace from test case is here. I also don't know if this happens with other DRI drivers, and whether this is a bug in the R600 specifically or something that should be fixed higher up in the common Mesa layers, but since the crash happens in the R600 driver I'm assuming that's the culprit. Program received signal SIGSEGV, Segmentation fault. 0x7724dd7f in r600_set_vertex_buffers (ctx=0x6154c0, count=1, buffers=0x7fffd5c0) at r600_state_common.c:165 165if (r600_buffer_is_user_buffer(buffers[i].buffer)) #0 0x7724dd7f in r600_set_vertex_buffers (ctx=0x6154c0, count=1, buffers=0x7fffd5c0) at r600_state_common.c:165 #1 0x77304b3c in st_draw_vbo (ctx=0xb48d80, arrays=, prims=0x7fffdb60, nr_prims=1, ib=0x0, index_bounds_valid=, min_index=0, max_index=2) at state_tracker/st_draw.c:701 #2 0x773012cb in vbo_draw_arrays (ctx=0xb48d80, mode=4, start=0, count=, numInstances=) at vbo/vbo_exec_array.c:588 #3 0x00400d85 in display () #4 0x0039f0020f75 in ?? () from /usr/lib64/libglut.so.3 #5 0x0039f0024ab9 in fgEnumWindows () from /usr/lib64/libglut.so.3 #6 0x0039f00214da in glutMainLoopEvent () from /usr/lib64/libglut.so.3 #7 0x0039f0021db5 in glutMainLoop () from /usr/lib64/libglut.so.3 #8 0x00400f00 in main () -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30483] r600g makes kwin (ab)use 100% CPU
https://bugs.freedesktop.org/show_bug.cgi?id=30483 ?yvind S?ther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:4045
Hi, my OS is a Debian testing with self compiled 2.6.36.1 vanilla kernel. CPU is "model name : Intel(R) Core(TM) i5 CPU 661 @ 3.33GHz" which contains the graphic chip and motherboard is an intel DH55HC. digest of boot log: [ 31.334582] [drm] Initialized drm 1.1.0 20060810 [ 31.347415] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 31.347420] i915 :00:02.0: setting latency timer to 64 [ 31.377104] i915 :00:02.0: irq 43 for MSI/MSI-X [ 31.377113] [drm] set up 31M of stolen space [ 32.100419] fb0: inteldrmfb frame buffer device [ 32.100421] drm: registered panic notifier [ 32.101007] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 $ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 41 2 2 2 IO-APIC-edge timer 1: 1078 1054 1007 1066 IO-APIC-edge i8042 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 4753 4806 4909 4787 IO-APIC-fasteoi ehci_hcd:usb1 17: 0 0 1 0 IO-APIC-fasteoi 23: 8 7 8 7 IO-APIC-fasteoi ehci_hcd:usb2 40: 563021 563010 562925 563092 PCI-MSI-edge eth0 41: 10340 10333 10243 10292 PCI-MSI-edge ahci 42: 17729 17816 17629 17817 PCI-MSI-edge hda_intel 43: 54557 54442 54760 54398 PCI-MSI-edge i915 NMI: 0 0 0 0 Non-maskable interrupts LOC: 423429 423651 430418 434414 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 102315 106505 109466 106257 Rescheduling interrupts CAL: 15015 5403 14241 4556 Function call interrupts TLB: 1068743685 1268 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 8 8 8 8 Machine check polls ERR: 3 MIS: 0 $ cat mtrr reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c000 ( 3072MB), size= 128MB, count=1: write-back reg03: base=0x0c800 ( 3200MB), size= 64MB, count=1: write-back reg04: base=0x1 ( 4096MB), size= 512MB, count=1: write-back reg05: base=0x12000 ( 4608MB), size= 128MB, count=1: write-back reg06: base=0x0d000 ( 3328MB), size= 256MB, count=1: write-combining digest of lspci -v -n 00:02.0 0300: 8086:0042 (rev 02) (prog-if 00 [VGA controller]) Subsystem: 8086:0036 Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at fe00 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at f100 [size=8] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 I switched to another user in X, opened a flash video and switched back to the screen of the first user. The screen kept blank and dmesg shows the following digest: [129031.110919] [ cut here ] [129031.110952] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:4045! [129031.110986] invalid opcode: [#1] SMP [129031.111012] last sysfs file: /sys/devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sdb/uevent [129031.111059] CPU 1 [129031.111071] Modules linked in: cbc aesni_intel cryptd aes_x86_64 aes_generic ecb dm_snapshot ecryptfs i915 drm_kms_helper drm i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect ip6table_filter ip6_tables iptable_filter ip_tables x_tables acpi_cpufreq mperf cpufreq_stats cpufreq_conservative cpufreq_userspace cpufreq_powersave kvm_intel kvm binfmt_misc fuse nls_utf8 bridge stp llc ipv6 reiserfs ext2 loop msr w83627ehf hwmon_vid cifs dm_crypt snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd evdev video output button soundcore snd_page_alloc processor ext4 mbcache jbd2 crc16 usbhid hid dm_mirror dm_region_hash dm_log dm_mod sd_mod ahci libahci libata ehci_hcd scsi_mod e1000e thermal thermal_sys [last unloaded: scsi
[PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote: > On Monday 06 December 2010, David Sin wrote: > > Tiling and Isometric Lightweight Engine for Rotation (TILER) driver > > = > > > > Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. > > Within the DMM exists at least one TILER hardware component. Its purpose > > is to > > organize video/image memory in a 2-dimensional fashion to limit memory > > bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver > > facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the > > TILER container(s). It also facilitates rotating and mirroring the > > allocated > > blocks or its rectangular subsections. > > How does this relate to DRM/GEM? I don't understand too much about graphics > drivers, but it does sound like there is some overlap in functionality. > > I guess at the very least the DMM should live in drivers/gpu/ instead of > drivers/misc, but perhaps it could be integrated more closely with the > existing code there. > > Arnd Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) for x86? I'm trying to understand the differences and make a case that it's not the same as DMM/TILER. thanks, -- David Sin
[PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 11:25:31AM -0600, David Sin wrote: > On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote: > > On Monday 06 December 2010, David Sin wrote: > > > Tiling and Isometric Lightweight Engine for Rotation (TILER) driver > > > = > > > > > > Dynamic Memory Manager (DMM) is a hardware block made by Texas > > > Instruments. > > > Within the DMM exists at least one TILER hardware component. Its purpose > > > is to > > > organize video/image memory in a 2-dimensional fashion to limit memory > > > bandwidth and facilitate 0 effort rotation and mirroring. The TILER > > > driver > > > facilitates allocating, freeing, as well as mapping 2D blocks (areas) in > > > the > > > TILER container(s). It also facilitates rotating and mirroring the > > > allocated > > > blocks or its rectangular subsections. > > > > How does this relate to DRM/GEM? I don't understand too much about graphics > > drivers, but it does sound like there is some overlap in functionality. > > > > I guess at the very least the DMM should live in drivers/gpu/ instead of > > drivers/misc, but perhaps it could be integrated more closely with the > > existing code there. > > > > Arnd > Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) > for x86? I'm trying to understand the differences and make a case that > it's not the same as DMM/TILER. > > thanks, > -- > David Sin Hi Arnd, I'm not sure exactly how DRM/GEM works.. What functionality do you think is overlapping? The main feature, aside from reduced page accesses, of the DMM hw block is to provide physically contiguous 2 dimensional memory blocks for image and video processing. This hw sits between the interconnect and the ext memory interface in the OMAP, and contains an MMU-like address traslator for "virtually" physically contiguous memory and sdram pages. thank you for your comments. BR, -- David Sin
[PATCH 0/9] TI DMM-TILER driver
On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote: > As far as I can tell, both DMM and GEM at a high level manage objects > in video memory. The IOMMU that you have on the Omap hardware seems > to resemble the GART that sits between PC-style video cards and main > memory. > > I don't know any details, but google quickly finds > http://lwn.net/Articles/283798/ with a description of the > initial GEM design. My main thought when looking over the > DMM code was that this should not be tied too closely to a > specific hardware, and GEM seems to be an existing abstraction > that may fit what you need. > > Arnd Thanks for the pointer, Arnd. I also found a nice readme file in the gpu/drm directory, which points to a wiki and source code. I'll read into this and get back to you. BR, -- David Sin
[PATCH 09/10] MCDE: Add build files and bus
On 11/26/2010 12:24 PM, Arnd Bergmann wrote: > [dri people: please have a look at the KMS discussion way below] > > On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote: > >>> -Original Message- >>> From: Arnd Bergmann [mailto:arnd at arndb.de] >>> Sent: den 25 november 2010 17:48 >>> To: Marcus LORENTZON >>> Cc: linux-arm-kernel at lists.infradead.org; Jimmy RUBIN; linux- >>> media at vger.kernel.org; Dan JOHANSSON; Linus WALLEIJ >>> Subject: Re: [PATCH 09/10] MCDE: Add build files and bus >>> >>> On Thursday 25 November 2010, Marcus LORENTZON wrote: >>> From: Arnd Bergmann [mailto:arnd at arndb.de] > On Wednesday 10 November 2010, Jimmy Rubin wrote: > >> This patch adds support for the MCDE, Memory-to-display >> >>> controller, >>> >> found in the ST-Ericsson ux500 products. >> >> > [note: please configure your email client properly so it keeps > proper attribution of text and and does not rewrap the citations > incorrectly. Wrap your own text after 70 characters] > I'm now using Thunderbird, please let me know if it's better than my previous webmail client, neither have many features for reply formatting. >>> All devices that you cannot probe by asking hardware or firmware are >>> normally >>> considered platform devices. Then again, a platform device is usally >>> identified by its resources, i.e. MMIO addresses and interrupts, which >>> I guess your display does not have. >>> >> Then we might be on right track to model them as devices on a >> platform bus. Since most displays/panels can't be "plug-n-play" >> probed, instead devices has to be statically declared in >> board-xx.c files in mach-ux500 folder. Or is platform bus a >> "singleton"? Or can we define a new platform bus device? >> Displays like HDMI TV-sets are not considered for device/driver >> in mcde. Instead there will be a hdmi-chip-device/driver on the >> mcde bus. So all devices and drivers on this bus are static. >> > I think I need to clarify to things: > > * When I talk about a bus, I mean 'struct bus_type', which identifies >all devices with a uniform bus interface to their parent device >(think: PCI, USB, I2C). You seem to think of a bus as a specific >instance of that bus type, i.e. the device that is the parent of >all the connected devices. If you have only one instance of a bus >in any system, and they are all using the same driver, do not add >a bus_type for it. >A good reason to add a bus_type would be e.g. if the "display" >driver uses interfaces to the dss that are common among multiple >dss drivers from different vendors, but the actual display drivers >are identical. This does not seem to be the case. > Correct, I refer to the device, not type or driver. I used a bus type since it allowed me to setup a default implementation for each driver callback. So all drivers get generic implementation by default, and override when that is not enough. Meybe you have a better way of getting the same behavior. > * When you say that the devices are static, I hope you do not mean >static in the C language sense. We used to allow devices to be >declared as "static struct" and registered using >platform_device_register (or other bus specific functions). This >is no longer valid and we are removing the existing users, do not >add new ones. When creating a platform device, use >platform_device_register_simple or platform_device_register_resndata. > > I'm not sure what you mean with drivers being static. Predefining > the association between displays and drivers in per-machine files is > fine, but since this is really board specific, it would be better > to eventually do this through data passed from the boot loader, so > you don't have to have a machine file for every combination of displays > that is in the field. > I guess you have read the ARM vs static platform_devices. But, yes, I mean in the c-language static sense. I will adopt to whatever Russel King says is The right way in ARM SoCs. >>> Staging it in a way that adds all the display drivers later than the >>> base driver is a good idea, but it would be helpful to also add the >>> infrastructure at the later stage. Maybe you can try to simplify the >>> code for now by hardcoding the single display and remove the dynamic >>> registration. You still have the the code, so once the base code looks >>> good for inclusion, we can talk about it in the context of adding >>> dynamic display support back in, possibly in exactly the way you are >>> proposing now, but perhaps in an entirely different way if we come up >>> with a better solution. >>> >> What about starting with MCDE HW, which is the core HW driver doing >> all real work? And then continue with the infrastructure + some displays >> + drivers ... > This is already the order in which you submitted them, I d
Linux 2.6.37-rc6
Hi,
On Wed, Dec 15, 2010 at 07:10:28PM -0800, ext Linus Torvalds wrote:
>
> Go forth and test. And please do remember to ping bugzilla (or
> developers) about any regressions you find, whether new or old.
I have some problem with i945, display remains blank. I also tried
adding i915.modeset=0 but nothing changed. Machine is well alive and
responds to basic commands like Ctrl+Alt+F1 and Ctrl+Alt+Del but I have
not other machine to enter via network.
Since it was working in -rc5, I bisected it. It boiled down to
ea5d552c73707645c53d42e8a71c9a4d9cbb85c1 but it's not the right commit
since everything still works with it. And I'm officially confused.
Unfortunately I cannot play too much with this box so please give me
some clever suggestion to be more efficient. Anyway I'll try also at
home on a i915 :)
I attached configuration and boot log.
thanks,
Domenico
> Alex Deucher (4):
> drm/radeon/kms: fix formatting of vram and gtt info
> drm/radeon/kms: fix vram base calculation on rs780/rs880
> drm/kms: remove spaces from connector names (v2)
> drm/radeon/kms: don't apply 7xx HDP flush workaround on AGP
>
> Chris Wilson (10):
> drm/i915: Clean conflicting modesetting registers upon init
> drm/i915: Death to the unnecessary 64bit divide
> drm/i915: Factor in pixel-repeat in FDI M/N calculation
> drm/i915/ringbuffer: Only print an error on the second attempt to reset
> head
> drm/i915/lvds: Always restore panel-fitter when enabling the LVDS
> drm/i915: Emit a request to clear a flushed and idle ring for unbusy bo
> drm/i915/dp: Only apply the workaround if the select is still active
> drm: Add missing drm_vblank_put() along queue vblank error path
> drm: Don't try and disable an encoder that was never enabled
> ACPI: video: fix build for CONFIG_ACPI=n
>
> Daniel Vetter (1):
> drm/i915: announce to userspace that the bsd ring is coherent
>
> Dave Airlie (1):
> drm/i915: i915 cannot provide switcher services.
>
> Eric Anholt (2):
> drm/i915: Always set the DP transcoder config to 8BPC.
> drm/i915: Apply a workaround for transitioning from DP on pipe B to
> HDMI.
-- next part --
[0.00] Linux version 2.6.37-rc6 (cavok at vixen) (gcc version 4.4.5
20100902 (prerelease) (Debian 4.4.4-13) ) #24 SMP PREEMPT Thu Dec 16 14:38:09
CET 2010
[0.00] Command line: ro root=/dev/sda1 resume=/dev/sda4
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009e000 (usable)
[0.00] BIOS-e820: 0009e000 - 000a (reserved)
[0.00] BIOS-e820: 000e4000 - 0010 (reserved)
[0.00] BIOS-e820: 0010 - bf6e (usable)
[0.00] BIOS-e820: bf6e - bf6ed000 (ACPI data)
[0.00] BIOS-e820: bf6ed000 - bf70 (ACPI NVS)
[0.00] BIOS-e820: bf70 - c000 (reserved)
[0.00] BIOS-e820: fec0 - fed0 (reserved)
[0.00] BIOS-e820: fee0 - fef0 (reserved)
[0.00] BIOS-e820: ffb8 - 0001 (reserved)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI present.
[0.00] No AGP bridge found
[0.00] last_pfn = 0xbf6e0 max_arch_pfn = 0x4
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [880f7520] f7520
[0.00] init_memory_mapping: -bf6e
[0.00] ACPI: RSDP 000f7580 00024 (v02 PTLTD )
[0.00] ACPI: XSDT bf6e8476 00064 (v01 PTLTD ? XSDT 0005
LTP )
[0.00] ACPI: FACP bf6e854e 000F4 (v03 FSC { 0005
000F4240)
[0.00] ACPI: DSDT bf6e8642 0453F (v01 FSCD21510005
MSFT 0202)
[0.00] ACPI: FACS bf6edfc0 00040
[0.00] ACPI: ASF! bf6ecb81 00085 (v16 OEMID OEMTBL 0005
PTL 0001)
[0.00] ACPI: SSDT bf6ecc06 0017C (v01 FSCEISTCPU0 0005
CSF 0001)
[0.00] ACPI: SSDT bf6ecd82 0017C (v01 FSCEISTCPU1 0005
CSF 0001)
[0.00] ACPI: MCFG bf6ecefe 00040 (v01 PTLTDMCFG 0005
LTP )
[0.00] ACPI: HPET bf6ecf3e 00038 (v01 PTLTD HPETTBL 0005
LTP 0001)
[0.00] ACPI: APIC bf6ecf76 00062 (v01 FSC? APIC 0005
CSF )
[0.00] ACPI: BOOT bf6ecfd8 00028 (v01 PTLTD $SBFTBL$ 0005
LTP 0001)
[0.00] Zone PFN ranges:
[0.00] DMA 0x0010 -> 0x1000
[0.00] DMA320x1000 -> 0x0010
[0.00] Normal empty
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00]
Linux 2.6.37-rc6
On Thu, 16 Dec 2010 18:30:11 +0100, Domenico Andreoli wrote: > Hi, > > On Wed, Dec 15, 2010 at 07:10:28PM -0800, ext Linus Torvalds wrote: > > > > Go forth and test. And please do remember to ping bugzilla (or > > developers) about any regressions you find, whether new or old. > > I have some problem with i945, display remains blank. I also tried > adding i915.modeset=0 but nothing changed. Machine is well alive and > responds to basic commands like Ctrl+Alt+F1 and Ctrl+Alt+Del but I have > not other machine to enter via network. If i915.modeset=0 doesn't restore the display then something is extremely fishy. Do you see any console output before the i915.ko is loaded? > [1.284262] [drm] Initialized drm 1.1.0 20060810 > [1.284334] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > [1.485212] vgaarb: device changed decodes: > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > [1.485642] [drm] initialized overlay support > [2.526011] No connectors reported connected with modes > [2.526053] [drm] Cannot find any crtc or sizes - going 1024x768 The issue appears to be that no outputs are being detected. I presume that you have instead a VGA connected to the box and that the regression is in fact e7dbb2f2. If I'm guessing rightly: diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 8df5743..14c276e 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -148,7 +148,9 @@ static void intel_crt_mode_set(struct drm_encoder *encoder, dpll_md & ~DPLL_MD_UDI_MULTIPLIER_MASK); } - adpa = ADPA_HOTPLUG_BITS; + adpa = 0; + if (INTEL_INFO(dev)->gen >= 4) + adpa |= ADPA_HOTPLUG_BITS; if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC) adpa |= ADPA_HSYNC_ACTIVE_HIGH; if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC) -- Chris Wilson, Intel Open Source Technology Centre
BUG: i915 causes NULL pointer dereference in 2.6.37-rc5-git4
On ?roda, 15 grudnia 2010 o 11:48:21 T?nu Raitviir wrote: > Asus P5E-VM HDMI motherboard with G35 chipset, only HDMI output is > connected. Last known good kernel was 2.6.36.2 > > 00:02.0 VGA compatible controller: Intel Corporation 82G35 Express > Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel > Corporation 82G35 Express Integrated Graphics Controller (rev 03) I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=25012 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.maciek.unixy.pl
[Bug 32455] New: Crash with mame using OpenGL with newest Gallium on Radeon 4350
https://bugs.freedesktop.org/show_bug.cgi?id=32455 Summary: Crash with mame using OpenGL with newest Gallium on Radeon 4350 Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: bitbytebit at gmail.com This is a backtrace of the issue, seems the first buffer is 0x0 and crashing on that in the r600g Gallium driver. This is running the newest Mame using OpenGL, Linux-Next, everything basically from GIT and newest up to date code. I suspect something in Mame might be causing the first buffer to be NULL, but not sure and it works on Classic so something is different in Gallium I am guessing. arcade mesa # lspci -v -s 01:00.0 01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (prog-if 00 [VGA controller]) Subsystem: Diamond Multimedia Systems Device 4350 Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at c8b0 (64-bit, non-prefetchable) [size=64K] I/O ports at 2000 [size=256] [virtual] Expansion ROM at e01e [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information Kernel driver in use: radeon Kernel modules: radeon Linux arcade 2.6.37-rc5-next-20101213 #1 SMP Tue Dec 14 18:23:46 CST 2010 i686 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux (gdb) run pacman -verbose Starting program: /mnt/livecd/usr/games/bin/mame pacman -verbose [Thread debugging using libthread_db enabled] Parsing mame.ini [New Thread 0xb6f4db70 (LWP 25175)] Build version: 0.140u2 (Dec 16 2010) Build architecure: SDLMAME_ARCH= Build defines 1:SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1 Build defines 1:LSB_FIRST=1 MAME_DEBUG=1 DISTRO=generic SYNC_IMPLEMENTATION=tc SDL/OpenGL defines: SDL_COMPILEDVERSION=1214 USE_OPENGL=1 USE_DISPATCH_GL=1 Compiler defines A: __GNUC__=4 __GNUC_MINOR__=4 __GNUC_PATCHLEVEL__=4 __VERSION__="4.4.4" Compiler defines B: __unix__=1 __i386__=1 Compiler defines C: __USE_FORTIFY_LEVEL=0 SDL Device Driver : x11 SDL Monitor Dimensions: 648 x 480 Enter sdlwindow_init Using SDL single-window OpenGL driver (SDL 1.2) Leave sdlwindow_init 648x 480 -> 0.001621 Loaded opengl shared library: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable OpenGL: X.Org OpenGL: Gallium 0.4 on AMD RV710 OpenGL: 2.1 Mesa 7.10-devel OpenGL: texture rectangle supported OpenGL: non-power-of-2 textures supported (new method) OpenGL: vertex buffer supported OpenGL: pixel buffers supported OpenGL: framebuffer object supported OpenGL: GLSL supported, but disabled OpenGL: max texture size 8192 x 8192 Keyboard: Start initialization Input: Adding Kbd #1: System keyboard Keyboard: Registered System keyboard Keyboard: End initialization Mouse: Start initialization Input: Adding Mouse #1: System mouse Mouse: Registered System mouse Mouse: End initialization Joystick: Start initialization Joystick: End initialization Audio: Start initialization Audio: Driver is alsa [New Thread 0xb565eb70 (LWP 25176)] Audio: frequency: 48000, channels: 2, samples: 1024 sdl_create_buffers: creating stream buffer of 57344 bytes Audio: End initialization ouput: unable to open output notifier file /tmp/sdlmame_out Input: Changing default joystick map = s8.4s8.44s8.4445 s888s 4s8s6 44s888s66 444555666 444555666 444555666 44s222s66 4s2s6 s222s Input: Changing default joystick map = s8.4s8.44s8.4445 s888s 4s8s6 44s888s66 444555666 444555666 444555666 44s222s66 4s2s6 s222s Matching font: /usr/share/fonts/liberation-fonts/LiberationSans-Regular.ttf 648x 480 -> 0.001621 Starting Driver Device 'root' (missing dependencies; rescheduling) Starting Z80 'maincpu' Starting Video Screen 'screen' Starting Speaker 'mono' (missing dependencies; rescheduling) Starting Namco 'namco' Starting Driver Device 'root' (missing dependencies; rescheduling) Starting Speaker 'mono' Starting Driver Device 'root' OpenGL: VBO supported OpenGL: PBO supported OpenGL: FBO supported OpenGL: using vid filter: 0 GL texture: copy 1, shader 0, dynamic 1, 288x224 288x224 [PALETTE16, Equal: 0, Palette: 1, scale 1x1, border 0, pitch 384,288/8192], colors: 512, bytes/pix 4 Program received signal SIGSEGV, Segmentation fault. 0xb5c01eec in r600_buffer_is_user_buffer (buffer=0x0) at r600_resource.h:103 103r600_resource.h: No such file or directory. in r600_resource.h (gdb) backtrace #0 0xb5c01eec in r600_buffer_is_user_buffer (buffer=0x0) at r600_resou
[Bug 32456] New: r600g makes sdlmame SIGSEGV, r600_set_vertex_buffers involvement indicated
https://bugs.freedesktop.org/show_bug.cgi?id=32456 Summary: r600g makes sdlmame SIGSEGV, r600_set_vertex_buffers involvement indicated Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: low Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: oyvinds at everdot.org 1. run sdlmame. 2. it dies on SIGSEGV, Segmentation fault. gdb sdlmame (gdb) run -video opengl -rompath /public/net/godzilla/games/MAME/roms/ mslug2 Starting program: /usr/games/bin/sdlmame -video opengl -rompath /public/net/godzilla/games/MAME/roms/ mslug2 [Thread debugging using libthread_db enabled] Warning: unknown option in INI: useallheads Warning: unknown option in INI: useallheads [New Thread 0x7427e710 (LWP 29182)] [New Thread 0x704e9710 (LWP 29183)] WARNING: Couldn't find/open TrueType font Liberation Sans, using MAME default Program received signal SIGSEGV, Segmentation fault. 0x72188339 in r600_set_vertex_buffers () from /usr/lib64/dri/r600_dri.so (gdb) bt #0 0x72188339 in r600_set_vertex_buffers () from /usr/lib64/dri/r600_dri.so #1 0x7223959c in st_draw_vbo () from /usr/lib64/dri/r600_dri.so #2 0x722362a3 in vbo_draw_arrays () from /usr/lib64/dri/r600_dri.so #3 0x00ff96f9 in drawogl_window_draw(_sdl_window_info*, unsigned int, int) () #4 0x00ff1cc6 in draw_video_contents_wt(void*, int) () #5 0x00ff2fc6 in sdlwindow_video_window_update(running_machine*, _sdl_window_info*) () #6 0x00fd39ac in sdl_osd_interface::update(bool) () #7 0x016206c4 in video_manager::frame_update(bool) () #8 0x015ebd47 in display_loading_rom_message(_romload_private*, char const*) () #9 0x015ecf9f in process_rom_entries(_romload_private*, char const*, rom_entry const*) () #10 0x015edf17 in rom_init(running_machine*) () #11 0x01597b02 in running_machine::start() () #12 0x0159803b in running_machine::run(bool) () #13 0x015963d0 in mame_execute(osd_interface&, _core_options*) () #14 0x0154fbe5 in cli_execute(int, char**, osd_interface&, _options_entry const*) () #15 0x00fd03bf in main () (gdb) quit -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800
?lmos changed:
What|Removed |Added
Attachment #41170|0 |1
is obsolete||
--- Comment #22 from ?lmos 2010-12-16 15:18:11 PST ---
Created an attachment (id=41192)
View: https://bugs.freedesktop.org/attachment.cgi?id=41192
Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41192
r300g_multitexturing_v2.diff
Yes, your calculations are OK. The problem is the
if (&state->sampler_views[i]->base != views[i]) {}
part, which leaves some samplers untouched, and their cache regions get reused
sometimes.
My attached patch is IMHO significantly better than the previous one. It
completely fixes texturing in etqw, but there are occasional glitches in ut2004
and the water in googleearth is still bad. See the TODO and XXX comments in the
patch for more explanation.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH] drm/radeon/kms: fix DCE4.1 dig routing
Works just like DCE4.0 despite what the docs say.
This fixes blank screen issues when changing crtc
routing due to incorrect crtc to dig mapping.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 17 +++--
1 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index e4e64a8..10ba103 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -910,15 +910,9 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
else
args.v3.ucLaneNum = 4;
- if (ASIC_IS_DCE41(rdev)) {
- args.v3.acConfig.ucEncoderSel = dig->dig_encoder;
- if (dig->linkb)
- args.v3.acConfig.ucLinkSel = 1;
- } else {
- if (dig->linkb) {
- args.v3.acConfig.ucLinkSel = 1;
- args.v3.acConfig.ucEncoderSel = 1;
- }
+ if (dig->linkb) {
+ args.v3.acConfig.ucLinkSel = 1;
+ args.v3.acConfig.ucEncoderSel = 1;
}
/* Select the PLL for the PHY
@@ -1535,11 +1529,6 @@ static int radeon_atom_pick_dig_encoder(struct
drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig;
uint32_t dig_enc_in_use = 0;
- /* on DCE41 and encoder can driver any phy so just crtc id */
- if (ASIC_IS_DCE41(rdev)) {
- return radeon_crtc->crtc_id;
- }
-
if (ASIC_IS_DCE4(rdev)) {
dig = radeon_encoder->enc_priv;
switch (radeon_encoder->encoder_id) {
--
1.7.2.3
[PATCH] drm/radeon/kms: fix DCE4.1 dig routing (v2)
Works more like DCE4.0 despite what the docs say.
This fixes blank screen issues when changing crtc
routing due to incorrect crtc to dig mapping.
v2: only two DIGx blocks, routing is hardcoded
based on link.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 54 ++
1 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index e4e64a8..55b84b8 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -910,15 +910,9 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
else
args.v3.ucLaneNum = 4;
- if (ASIC_IS_DCE41(rdev)) {
- args.v3.acConfig.ucEncoderSel = dig->dig_encoder;
- if (dig->linkb)
- args.v3.acConfig.ucLinkSel = 1;
- } else {
- if (dig->linkb) {
- args.v3.acConfig.ucLinkSel = 1;
- args.v3.acConfig.ucEncoderSel = 1;
- }
+ if (dig->linkb) {
+ args.v3.acConfig.ucLinkSel = 1;
+ args.v3.acConfig.ucEncoderSel = 1;
}
/* Select the PLL for the PHY
@@ -1535,32 +1529,34 @@ static int radeon_atom_pick_dig_encoder(struct
drm_encoder *encoder)
struct radeon_encoder_atom_dig *dig;
uint32_t dig_enc_in_use = 0;
- /* on DCE41 and encoder can driver any phy so just crtc id */
- if (ASIC_IS_DCE41(rdev)) {
- return radeon_crtc->crtc_id;
- }
-
if (ASIC_IS_DCE4(rdev)) {
dig = radeon_encoder->enc_priv;
- switch (radeon_encoder->encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ if (ASIC_IS_DCE41(rdev)) {
if (dig->linkb)
return 1;
else
return 0;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- if (dig->linkb)
- return 3;
- else
- return 2;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- if (dig->linkb)
- return 5;
- else
- return 4;
- break;
+ } else {
+ switch (radeon_encoder->encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ if (dig->linkb)
+ return 1;
+ else
+ return 0;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ if (dig->linkb)
+ return 3;
+ else
+ return 2;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ if (dig->linkb)
+ return 5;
+ else
+ return 4;
+ break;
+ }
}
}
--
1.7.2.3
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #23 from Chris Rankin 2010-12-16 16:37:34 PST --- (In reply to comment #22) > My attached patch is IMHO significantly better than the previous one. The patch may be flawed, but it greatly improves WoW as well. I've just run around a couple of "texture hotspots" without noticing any problems, although the console log has been warning me of "trouble ahead" a fair bit as well. I would say that the patch is definitely heading in the correct general direction. (Although it doesn't apply cleanly to git. Perhaps it was made against altered sources?) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
