[Bug 11877] texture_srgb glGetTexImage failed for internalFormat GL_SRGB_EXT
http://bugs.freedesktop.org/show_bug.cgi?id=11877 --- Comment #4 from [EMAIL PROTECTED] 2007-09-16 23:21 PST --- But, according to the OpenGL spec: 'sRGB values are returned as-is without an sRGB-to-linear conversion.' So, sRGB values should still be correctly returned for R, G, B, and A component respectively. Just sRGB-to-linear conversion is not performed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12453] New: polygon face culling doesn't work well in DRI mode
http://bugs.freedesktop.org/show_bug.cgi?id=12453 Summary: polygon face culling doesn't work well in DRI mode Product: Mesa Version: CVS Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i965 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: dri-devel@lists.sourceforge.net this issue only happens in DRI mode when FRONT face is set to GL_POINT mode, and BACK face is set to GL_FILL mode enable GL_CULL_FACE, and cull FRONT face the expected result is only FRONT face being culled away. but here we found BACK face is also affected (BACK face change to take the color we set for FRONT face) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12453] polygon face culling doesn't work well in DRI mode
http://bugs.freedesktop.org/show_bug.cgi?id=12453 --- Comment #1 from [EMAIL PROTECTED] 2007-09-17 00:43 PST --- Created an attachment (id=11598) -- (http://bugs.freedesktop.org/attachment.cgi?id=11598action=view) test case we set green for FRONT face, blue for BACK face after culling the FRONT face the triangle left there should be in blue. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #8 from [EMAIL PROTECTED] 2007-09-17 04:20 PST --- *** Bug 6463 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #9 from [EMAIL PROTECTED] 2007-09-17 04:23 PST --- *** Bug 12443 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
On 09/09/2007 04:43 PM, Jiri Slaby wrote:
On 09/09/2007 04:33 PM, Andi Kleen wrote:
On Sun, Sep 09, 2007 at 04:26:22PM +0200, Jiri Slaby wrote:
BTW it is reproducible for me on two different machines (i386-x86_64,
radeon-intel), don't you have the problem too?
No problems here with a radeon, no.
Does your CPU have clflush or not in /proc/cpuinfo?
BTW this is how my flush_kernel_map looks like:
static void flush_kernel_map(void *arg)
{
struct flush_arg *a = (struct flush_arg *)arg;
struct page *pg;
unsigned int xx = 0;
/* When clflush is available use it because it is
much cheaper than WBINVD. */
printk(%s: 1\n, __func__);
if (a-full_flush || !cpu_has_clflush)
asm volatile(wbinvd ::: memory);
else list_for_each_entry(pg, a-l, lru) {
printk(%s: %10u 1a\n, __func__, xx++);
if (PageFlush(pg))
clflush_cache_range(page_address(pg), PAGE_SIZE);
}
printk(%s: 2\n, __func__);
__flush_tlb_all();
printk(%s: 3\n, __func__);
}
It outputs 1a in the infinite loop with incrementing xx. But only in this
case,
some global_flush_tlb are OK. e.g.:
Sep 10 01:39:19 localhost kernel: agpgart: Detected an Intel G33 Chipset.
Sep 10 01:39:19 localhost kernel: global_flush_tlb: 1
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2
Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3
Sep 10 01:39:19 localhost kernel: global_flush_tlb: 2
Sep 10 01:39:19 localhost kernel: global_flush_tlb: 3
Sep 10 01:39:19 localhost kernel: agpgart: Detected 6140K stolen memory.
It seems, that the list is broken only on X shutdown. How can be
deferred-pages
list inited in some bad manner, when list_replace_init is called on it? Weird.
Ok, here comes a BUG with trace:
set status page addr 0x00033000
list_add corruption. next-prev should be prev (8068ae70), but was
80697a50. (next=81000117fbd0).
[ cut here ]
kernel BUG at /home/l/latest/xxx/lib/list_debug.c:27!
invalid opcode: [1] SMP
last sysfs file: /devices/pci:00/:00:02.0/enable
CPU 0
Modules linked in: ipv6 floppy sr_mod rtc_cmos rtc_core cdrom ehci_hcd rtc_lib
usbhid
Pid: 1639, comm: X Not tainted 2.6.23-rc4-mm1_64 #23
RIP: 0010:[80332f49] [80332f49] __list_add+0x39/0x60
RSP: 0018:81000547bd48 EFLAGS: 00010296
RAX: 0079 RBX: 81000117a380 RCX: 8068b450
RDX: 81000317d6a0 RSI: 0001 RDI: 8068b420
RBP: 81000547bd48 R08: R09: 0001
R10: 0001 R11: R12: 6da2
R13: 810006c10d10 R14: 810006da2000 R15: 8163
FS: 7f7a05258710() GS:806d1000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00a33040 CR3: 04a43000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process X (pid: 1639, threadinfo 81000547a000, task 81000317d6a0)
Stack: 81000547bd58 80332f7c 81000547bdc8 80225c56
80225cb5 8163 806830e8 806830a0
806830a0 810006da2000 81000547bda8 6da2
Call Trace:
[80332f7c] list_add+0xc/0x10
[80225c56] __change_page_attr+0x376/0x390
[80225cb5] change_page_attr_addr+0x45/0x140
[80225d16] change_page_attr_addr+0xa6/0x140
[80225de3] change_page_attr+0x33/0x40
[80387b64] agp_generic_destroy_page+0x44/0x70
[80388645] agp_free_memory+0x65/0xd0
[80386d49] agp_free_memory_wrap+0x39/0x60
[803873fb] agp_release+0xdb/0x1c0
[80299551] __fput+0xd1/0x1b0
[802996b6] fput+0x16/0x20
[802964e6] filp_close+0x56/0x90
[80297bed] sys_close+0xad/0x110
[8020bd0e] system_call+0x7e/0x83
INFO: lockdep is turned off.
Code: 0f 0b eb fe 0f 1f 00 48 89 f1 4c 89 c2 48 89 c6 48 c7 c7 e8
RIP [80332f49] __list_add+0x39/0x60
RSP 81000547bd48
regards,
--
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk University
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 --- Comment #10 from [EMAIL PROTECTED] 2007-09-17 05:25 PST --- Created an attachment (id=11602) -- (http://bugs.freedesktop.org/attachment.cgi?id=11602action=view) screen corruption w/ patch 11358 screen corruption occurs at the top of the screen on T43p -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 --- Comment #11 from [EMAIL PROTECTED] 2007-09-17 05:27 PST --- Created an attachment (id=11603) -- (http://bugs.freedesktop.org/attachment.cgi?id=11603action=view) xlog for 11602 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ttm --- dealing with (more) limited memory pools
I've got a couple of things that are bothering me if we're looking at finalizing the TTM interface in the near term. Specifically I'm concerned that we don't have a recoverable way to deal with out-of-memory situations. Consider a driver that tries to submit whole frames of q3, which is running on say a 32mb card. There's nothing to stop the driver specifying textures in excess of what is available to the memory manager. If the driver does do this, there's no feedback from the kernel that this is a band idea until after it's done. Also, all the geometry is now gone, so it's too late to restructure the command stream or even fall back to software. Note this is a different situation to using 8 huge textures to draw a single triangle, where nothing can be done to help. In the case above, the scene could be split and rendered on hardware, although at the expense of texture thrashing. We've benefited from the flexibilty with IGPs to avoid this so far, but we do want to cope with VRAM and it seems like we are currently missing some of the necessary mechanisms... So the issues are: - how does the driver know ahead of time it is running out of texture space? - if the answer to the above is it doesn't, then how do we rescue submitted command streams that exceed texture space? - relatedly, on cards with texture-from-vram and texture-from-agp, how does the driver know which pool to use for a particular texture? At worst, I can imagine something like the kernel pushing out to userspace a size for each pool which is guarenteed to be available for validated buffers. Eg, on a 32 mb card, we could say that there is a maximum no-evict space of 8mb, meaning that at all times there is at least 24 mb available for validated buffers. There may be more than that. The userspace driver would be responsible for ensuring that all the buffers it wants to validate to that pool do not exceed 24mb (given some alignment constraints???). When it approaches that limit, it can either switch to other pools or flush the command stream. If some of the 8mb is free, it can be used by the memory manager to avoid evicts. In the worst case, it just means that the userspace driver flushes more often than it strictly has to. It can even try and exceed the 24mb if it wants to, but has to live with the possibility of the memory manager saying 'no'. It still has access to the full amount of memory on the card not taken by no-evict buffers. So summarizing: - Enforce a limit on no-evict buffers. Keep these to a contigous region of the address space (XXX: note this makes pageflipping private backbuffers more complex). - Advertize the size of the remaining space. - Drivers monitor the total size of buffers referenced by relocations, and flush before it reaches the available space in any pool. - Drivers may try to reference more as long as they are prepared for failure. - The memory manager uses any extra space to avoid evicts. This seems like it can be implemented in the time available with minimal kernel changes. It also seems like it will probably work, and pushes most of the responsibility into the userspace driver, and allows it to make decisions as the stream is being built rather than trying to fix it up afterwards... Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #11603|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11870] AIGLX DRM Probe Removes RADEON DRM Lock
http://bugs.freedesktop.org/show_bug.cgi?id=11870 --- Comment #12 from [EMAIL PROTECTED] 2007-09-17 07:39 PST --- the driver still needs to have reasonableness checks like those described in http://bugs.freedesktop.org/show_bug.cgi?id=12443#c5 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12263] Some stencil op failed when draw bitmap
http://bugs.freedesktop.org/show_bug.cgi?id=12263 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from [EMAIL PROTECTED] 2007-09-17 18:26 PST --- fixed in mesa git e21d2c6ef300c7661f49c50b4c68b4f205795f4a -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11877] texture_srgb glGetTexImage failed for internalFormat GL_SRGB_EXT
http://bugs.freedesktop.org/show_bug.cgi?id=11877 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #5 from [EMAIL PROTECTED] 2007-09-17 20:18 PST --- So, I will reopen this bug -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
