[Bug 13439] [TTM i965]mesa demo fire crash Xorg
http://bugs.freedesktop.org/show_bug.cgi?id=13439 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13543] Draw bitmap incorrect if DepthFunc is GL_LESS
http://bugs.freedesktop.org/show_bug.cgi?id=13543 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13531] Seg fault when draw triangle if GL_LIGHT_MODEL_TWO_SIDE is TRUE and glFrontFace is GL_CW
http://bugs.freedesktop.org/show_bug.cgi?id=13531 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13442] [GM965 TTM]mesa demo glxgears hang system
http://bugs.freedesktop.org/show_bug.cgi?id=13442 --- Comment #5 from [EMAIL PROTECTED] 2007-12-10 01:16 PST --- we have updated the driver to latest version on gm965 (64bit OS). there are two different phenomenon when we use two methods to test 1) startx , run glxgears , after a while , the case run failed . and sometimes may crash X . 2) run X ,then run xterm , glxgears . this case can soon hang the system. And it is amazing that glxgears can run normally on g965(64 bit os) q965 (32 bit os). -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13585] New: Texture not rendered correctly when fragment program ATTRIB defined but not used
http://bugs.freedesktop.org/show_bug.cgi?id=13585 Summary: Texture not rendered correctly when fragment program ATTRIB defined but not used Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] This problem was observed on an Intel X3100 graphics adapter (965GM chipset), using the i915 DRM driver. Mesa was version 7.0.1-7.fc8. This particular issue only shows up on my intel 965 hardware - the exact same code running on an Nvidia Geforce 6600 looks correct. I am working on an N64 emulator which programmatically generates fragment programs for rendering. Sometimes it defines an ATTRIB which is not used in any instructions later in the code, and in this case the color value for every fragment in a polygon is the same - I assume this is because the texture coordinates are not being updated. The following fragment program exhibits the error: !!ARBfp1.0 TEMP t0; TEMP t1; TEMP comb; TEMP comb2; ATTRIB shade = fragment.color; TEX t0, fragment.texcoord[0], texture[0], 2D; TEX t1, fragment.texcoord[1], texture[1], 2D; MOV comb.rgb, t0 MOV comb.a, t0 MOV result.color, comb; END When running this fragment program, the texture is not displayed correctly; only a single color is used for all fragments. To work around this bug, either use the 'shade' ATTRIB in an instruction (such as change 'MOV comb.a, t0' to 'MOV comb.a, shade') or remove the ATTRIB line. -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: wait for buffer idle before writing relocations
Keith Packard wrote: On Fri, 2007-12-07 at 11:15 +, Keith Whitwell wrote: Keith, Thomas has just left for two weeks of (well deserved!) holiday, so he may be slow to respond. Thanks for taking the time to have a look while he's away; we're finishing up the 965 TTM work, and it is posing some challenges with the existing kernel interface. In the meantime, have you considered how this will interact with userspace buffer pools? No, I hadn't considered that as we're not considering a two-level allocation strategy at this point. However, if you consider the blocking patch in conjunction with the presumed_offset optimization, I think you'll find that userspace buffer pools will not actually be affected negatively by this change. The presumed_offset optimization allows the application to compute all relocations itself for target buffers which have been mapped to the hardware. The kernel relocations are purely a back-up, for cases where buffers move between EXECBUFFER invocations. I know you guys aren't using them at this point, but I'm of the opinion that they are an important facility which needs to be preserved. At worst it may be that some additional flag is needed to control this behaviour. We could do this, but I believe this would actually require more blocking by the client -- it doesn't know when objects are moving in the kernel, so it doesn't know when relocation data will need to be rewritten. Secondly I wonder whether this isn't already caught by other aspects of the buffer manager behaviour? ie, if the buffer to which the relocation points to is being moved, doesn't that imply all hardware activity related to that buffer must have concluded? IE, if the buffer itself is free to move, surely all commands containing relocations (or chains of relocations) which point to the buffer must themselves have completed?? Yes, if the target buffer is moving, then the operation related to the relocatee will have been completed and waited for. But, re-writing relocations doesn't require that the buffers have moved. Consider the case of the binding table on 965 which points at surface state structures. Executing a command that uses the binding table will require that relocations be evaluated for the entries in the table; even if nothing moves (ignoring my presumed_offset optimization), those relocations will need to be evaluated and the surface state pointers stored to the binding table. For the application to guarantee that the binding table relocations can be written without the kernel needing to wait for the binding table buffer to be idle, the application would have to wait every time, not just when the buffer actually moves. OK, it sounds like you're talking about situations where the driver is modifying state in buffers *only* through changes to the relocations? It's probably not surprising the fence is not implemented as I'd normally think that those relocation changes would be associated with some changes to the other data, and that would imply mapping the buffer (and hence the wait). I do understand the examples though and can see where you're trying to take this. Anyway, I'm hopeful that this won't break other usages... Keith - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13488] DRI Wiki Maintainance
http://bugs.freedesktop.org/show_bug.cgi?id=13488 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from [EMAIL PROTECTED] 2007-12-10 06:21 PST --- gabe-annarchy vhost migration complete... I'll give it a week for dns to settle before changing the wiki over - think you'll be the first fd.o site to use 1.6, I'll be interested in the spam support. (Changing State to NEEDINFO as bug is now in a delayed state) -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: wait for buffer idle before writing relocations
On Mon, 2007-12-10 at 13:27 +, Keith Whitwell wrote: OK, it sounds like you're talking about situations where the driver is modifying state in buffers *only* through changes to the relocations? Yes, although I also don't expect this to be common. It's probably not surprising the fence is not implemented as I'd normally think that those relocation changes would be associated with some changes to the other data, and that would imply mapping the buffer (and hence the wait). If the buffer was mapped (and waited for) by the client, then the kernel 'wait' will be free. I do understand the examples though and can see where you're trying to take this. Ok, thanks for thinking it through. Anyway, I'm hopeful that this won't break other usages... I think the interesting usage that you point out is where the application knows that a wait isn't necessary as the previously referenced data will not be re-used, and only new portions of the buffer need relocations. Given the choice between avoiding waits for cases we have today vs avoiding waits for cases we may try in the future, it seems reasonable to solve what we're using now. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: wait for buffer idle before writing relocations
Yeah, I'm pretty interested to come up with an 'append' type of semantic for buffer usage, particularly for things like the state pools you guys are probably playing with at the moment. It's not something that's ever going to be a *requirement* for a driver, and may not necessarily be a big win or even particularly difficult, but at this point nobody's really dug into it enough to know one way or another. Ignoring relocation issues, an 'append' mapping semantic, as opposed to the existing read/write maps, is probably an interesting concept also as it could allow mapping a state pool buffer to add new states as required by the application, but not require a fence as the old ones won't be interfered with. Keith - Original Message From: Keith Packard [EMAIL PROTECTED] To: Keith Whitwell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; dri-devel dri-devel@lists.sourceforge.net Sent: Monday, December 10, 2007 4:44:44 PM Subject: Re: i915: wait for buffer idle before writing relocations [...] I think the interesting usage that you point out is where the application knows that a wait isn't necessary as the previously referenced data will not be re-used, and only new portions of the buffer need relocations. Given the choice between avoiding waits for cases we have today vs avoiding waits for cases we may try in the future, it seems reasonable to solve what we're using now. -- [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8732] Composite breaks OpenGL
http://bugs.freedesktop.org/show_bug.cgi?id=8732 --- Comment #12 from [EMAIL PROTECTED] 2007-12-10 23:54 PST --- Any progress? This bug is over a year old. I bought a laptop with an intel graphics chip because I wanted to use a free software driver but obviously that was a mistake. Next time I'll go with an NVIDIA chip. The drivers may be proprietary but at least their stuff WORKS! It's nearly 2008, I should be able to have nice effects on my computer. KDE 4 is coming out soon and I won't be able to use it to it's full potential because this is BROKEN! -- 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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
