Re: Gallium code reorganization
Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 Michael Fu [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #6 from Michael Fu [EMAIL PROTECTED] 2008-02-15 01:29:55 PST --- Hi, would you able to test a newer driver, e.g. the 2.2.0.90 which was just released a couple of days ago? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 14510] New: DRI2 fails to unmap buffer
http://bugs.freedesktop.org/show_bug.cgi?id=14510 Summary: DRI2 fails to unmap buffer Product: DRI Version: DRI CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Starting glxgears or any application using DRI(2) it runs for about one second and after that fails: DRM_I830_EXECBUFFER: -16 glxgears: intel_context.c:856: UNLOCK_HARDWARE: Assertion `intel-batch-cliprect_mode != REFERENCES_CLIPRECTS' failed. dmesg says: [drm:drm_buffer_object_validate] *ERROR* Timed out waiting for buffer unmap. [drm:i915_validate_buffer_list] *ERROR* error on handle validate -16 I'm using Mesa, Xorg, drm (lib + kernel modules) from git of today. intel i945GM with xf86-video-intel branch origin/intel-batchbuffer. Kernel 2.6.24.2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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: Gallium code reorganization
OK, I found I had to merge rather than rebase in order to get my changes into the new organization -- apologies for the bubble in the history. Keith José Fonseca wrote: Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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: Gallium code reorganization
I think it is almost impossible to rebase under these circumstances. BTW, there was an unforeseen problem -- aux appears to be special file on windows. Hence I had to rename that directory to auxiliary... Jose On 2/15/08, Keith Whitwell [EMAIL PROTECTED] wrote: OK, I found I had to merge rather than rebase in order to get my changes into the new organization -- apologies for the bubble in the history. Keith José Fonseca wrote: Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. Jose - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 14510] DRI2 fails to unmap buffer
http://bugs.freedesktop.org/show_bug.cgi?id=14510 --- Comment #1 from Kristian Høgsberg [EMAIL PROTECTED] 2008-02-15 06:00:27 PST --- Could you: - attach the log - try running the X server under gdb, set a break point on abort and the attach the backtrace when the assertion fails Are you trying to run this in direct rendering mode? DRI2 is limited to indirect rendering for now (I'm going to post a heads up). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
DRI2 committed
Hello, Last night I committed the DRI2 work that I've been sitting on for quite a while now. This first code drop comes with a number of caveats, though: - only intel hardware, limited testing on i965 and up. Gotta reinstall that box... - everything committed on master, except the xf86-video-intel parts, which are committed on the intel-batchbuffer branch. - it's disabled by default, add 'Option DRI2' in the device section of xorg.conf to enable. - no direct rendering; I need to specify and implement the DRI2 protocol, and right now, the DRI2 module interface isn't quite set in stone. - problems with rendering to redirected windows. Well, duh, what's the point then... Anyway, the code is out there, shouldn't break anything unless you enable it, and I'll be working on the problems above so we can enable it by default later. I wrote a tutorial here on how to compile the entire stack: http://hoegsberg.blogspot.com/2008/02/building-and-installing-drmdrix-stack.html cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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: DRI2 committed
On Fri, Feb 15, 2008 at 1:58 PM, Carl Worth [EMAIL PROTECTED] wrote: On Fri, 15 Feb 2008 09:57:32 -0500, =?UTF-8?Q?Kristian_H=C3=B8gsberg?= wrote: Last night I committed the DRI2 work that I've been sitting on for quite a while now. Congratulations! - only intel hardware, limited testing on i965 and up. Gotta reinstall that box... Is that you've only tested i965 and that's been limited so far? Or you've tested other intel hardware thoroughly but the i965 test has only been limited? I can perhaps help with some i965 testing. Oops, you're right, that was unclear: I've tested on my i830 laptop and a i945 sony vaio, but not much on i965. I'm trying to bring the stack up on a i965 system right now, but any help is appreciated. - everything committed on master, except the xf86-video-intel parts, which are committed on the intel-batchbuffer branch. OK, and you mentioned in IRC that you'll look into merging that with the branches that Eric and I have been working on. That sounds great. Yes, I did my work on top of the upstrem intel-batchbuffer branch and also wasn't sure if Erics branch introduced performance regressions as compared to the upstream branch, so I decided to just merge it there as a first step. cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 13918] [965 TTM] glean case pointSprite segment fault
http://bugs.freedesktop.org/show_bug.cgi?id=13918 --- Comment #1 from Eric Anholt [EMAIL PROTECTED] 2008-02-15 11:08:31 PST --- So it must have failed with an error about the fence wait printed out Did the X server die soon after (other rendering failed due to chip hang?) I can't reproduce this on my GM965 system. -- 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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 13918] [965 TTM] glean case pointSprite segment fault
http://bugs.freedesktop.org/show_bug.cgi?id=13918 --- Comment #2 from Thomas Hellström [EMAIL PROTECTED] 2008-02-15 12:13:02 PST --- Actually it's entirely possible to fill the ring with rendering commands that will take more than 3 seconds to complete. I see that problem with gltestperf and i915 ttm. I'm not saying that's the problem here but it may be a candidate. It's hard to come up with a good way to solve this problem, but ideally we shouldn't rely on fences to detect timeouts. /Thomas -- 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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 13915] glDrawPixels segment fault if format is GL_DEPTH_COMPONENT and DrawBuffer set to GL_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=13915 Eric Anholt [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Eric Anholt [EMAIL PROTECTED] 2008-02-15 13:50:26 PST --- Fixed by two commits, eed5e6f40f1728ae5ae346d44ce45ba767bbf24c and c741d287ecce1bd95d4e024d60e274abfcfbe22f. Note that this testcase crashes with a pure software mesa, so it would be useful to see it make it into glean. -- 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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 13918] [965 TTM] glean case pointSprite segment fault
http://bugs.freedesktop.org/show_bug.cgi?id=13918 --- Comment #3 from Thomas Hellström [EMAIL PROTECTED] 2008-02-15 14:07:02 PST --- (In reply to comment #2) It's hard to come up with a good way to solve this problem, but ideally we shouldn't rely on fences to detect timeouts. err... detect lockups not timeouts. /Thomas -- 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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 13918] [965 TTM] glean case pointSprite segment fault
http://bugs.freedesktop.org/show_bug.cgi?id=13918 --- Comment #4 from Eric Anholt [EMAIL PROTECTED] 2008-02-15 14:21:12 PST --- Yeah, this has always been a problem, but things seem to have become more fragile since TTM. We should fix the fence wait code to do basically what we used to with irq waits from userland -- if the ring's made any progress, don't bail out yet. We should also probably reduce ring size once we've got everything going through batchbuffers, so that you don't end up with such huge queues to chew through (this is a problem for X where x11perf or a similar dump-rendering-without-waiting app destroys interactivity). Doing it today before we've moved 2D to batchbuffers may kill our already lackluster 2D performance. -- 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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
