[Bug 15851] [i915 i965] glean case logicOp failed if compiled with USE_SSE_ASM option
http://bugs.freedesktop.org/show_bug.cgi?id=15851 haihao [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from haihao [EMAIL PROTECTED] 2008-05-13 02:22:22 PST --- *** This bug has been marked as a duplicate of bug 15850 *** -- 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 15850] [i915 i965] glean case blendFunc failed if compiled with USE_SSE_ASM option
http://bugs.freedesktop.org/show_bug.cgi?id=15850 --- Comment #4 from haihao [EMAIL PROTECTED] 2008-05-13 02:22:22 PST --- *** Bug 15851 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 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
TTM merging?
Dave, Could you list what fixes / changes you think are needed to get TTM into the mainline kernel? /Thomas - 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: TTM merging?
Dave, Could you list what fixes / changes you think are needed to get TTM into the mainline kernel? 2 main reasons: 1) I feel there hasn't been enough open driver coverage to prove it. So far we have done an Intel IGD, we have a lot of code that isn't required for these devices, so the question of how much code exists purely to support poulsbo closed source userspace there is and why we need to live with it. Both radeon and nouveau developers have expressed frustration about the fencing internals being really hard to work with which doesn't bode well for maintainability in the future. 2) Intel have asked that we don't push i915 support upstream as they believe it isn't ready and as they end up supporting the kernel module in the longer term I cannot go against that without a good reason. I have no other driver to push hence stalled. I'll leave keithp to comment on this further. Dave. - 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: TTM merging?
Dave Airlie wrote: Dave, Could you list what fixes / changes you think are needed to get TTM into the mainline kernel? 2 main reasons: 1) I feel there hasn't been enough open driver coverage to prove it. So far we have done an Intel IGD, we have a lot of code that isn't required for these devices, so the question of how much code exists purely to support poulsbo closed source userspace there is and why we need to live with it. Both radeon and nouveau developers have expressed frustration about the fencing internals being really hard to work with which doesn't bode well for maintainability in the future. OK. So basically what I'm asking is that when we have full-feathered open source drivers available that utilize TTM, either as part of DRM core, or, if needed, as part of driver-specific code, do you see anything else that prevents that from being pushed? That would be very valuable to know for anyone starting porting work. ? /Thomas - 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 15728] [945GM][kernel 2.6.25] Fail to run GL program after resume
http://bugs.freedesktop.org/show_bug.cgi?id=15728 --- Comment #5 from Khashayar Naderehvandi [EMAIL PROTECTED] 2008-05-13 15:41:28 PST --- (In reply to comment #4) (In reply to comment #3) I can confirm having this problem on a stock hardy install which uses: mesa 7.0.3 xserver 1.4.0.90 intel: 2.2.1 @Jie Luo: Are you saying that you don't see the problem with the same setup as I have, except updated intel driver? And that the problem reappears when you update mesa and xserver to git? Yes. But as I didn't try intel driver 2.2.1, I don't know whether it works with kernel 2.6.25 in my system. In that case, I assume, the problem is not necessarily with the drm modules, no? I haven't managed to get 2.3.1 working properly on my g965 machine on ubuntu (the resolution isn't correct). But I will try to install Fedora 9 later on, when I have time, and see how things work out there. As far as I know, Fedora 9 ships a 2.6.25 kernel. (Note that I'm only interested in updated drm modules because the modules from kernel 2.6.24 cause a whole lot of VBLANK wakeups while running compiz) -- 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: TTM merging?
1) I feel there hasn't been enough open driver coverage to prove it. So far we have done an Intel IGD, we have a lot of code that isn't required for these devices, so the question of how much code exists purely to support poulsbo closed source userspace there is and why we need to live with it. Both radeon and nouveau developers have expressed frustration about the fencing internals being really hard to work with which doesn't bode well for maintainability in the future. OK. So basically what I'm asking is that when we have full-feathered open source drivers available that utilize TTM, either as part of DRM core, or, if needed, as part of driver-specific code, do you see anything else that prevents that from being pushed? That would be very valuable to know for anyone starting porting work. ? I was hoping that by now, one of the radeon or nouveau drivers would have adopted TTM, or at least demoed something working using it, this hasn't happened which worries me, perhaps glisse or darktama could fill in on what limited them from doing it. The fencing internals are very very scary and seem to be a major stumbling block. I do worry that TTM is not Linux enough, it seems you have decided that we can never do in-kernel allocations at any useable speed and punted the work into userspace, which makes life easier for Gallium as its more like what Windows does, but I'm not sure this is a good solution for Linux. The real question is whether TTM suits the driver writers for use in Linux desktop and embedded environments, and I think so far I'm not seeing enough positive feedback from the desktop side. Also wrt the i915 driver it has too many experiments in it, the i915 users need to group together and remove the codepaths that make no sense and come up with a ssuitable userspace driver for it, remove all unused fencing mechanisms etc.. Dave. /Thomas - 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: TTM merging?
Dave Airlie wrote: 1) I feel there hasn't been enough open driver coverage to prove it. So far we have done an Intel IGD, we have a lot of code that isn't required for these devices, so the question of how much code exists purely to support poulsbo closed source userspace there is and why we need to live with it. Both radeon and nouveau developers have expressed frustration about the fencing internals being really hard to work with which doesn't bode well for maintainability in the future. OK. So basically what I'm asking is that when we have full-feathered open source drivers available that utilize TTM, either as part of DRM core, or, if needed, as part of driver-specific code, do you see anything else that prevents that from being pushed? That would be very valuable to know for anyone starting porting work. ? I was hoping that by now, one of the radeon or nouveau drivers would have adopted TTM, or at least demoed something working using it, this hasn't happened which worries me, perhaps glisse or darktama could fill in on what limited them from doing it. The fencing internals are very very scary and seem to be a major stumbling block. Yes, it would be good to get some details here. Exactly what parts are scary? It seems Ian Romanick has made it work fine with xgi. 122 locs including license headers. I915 fencing can be made equally short if all sample (flushing) code is removed. I do worry that TTM is not Linux enough, it seems you have decided that we can never do in-kernel allocations at any useable speed and punted the work into userspace, which makes life easier for Gallium as its more like what Windows does, but I'm not sure this is a good solution for Linux. In-kernel allocations should be really fast unless they involve changing caching policy. If they are not, it's not a design issue but an implementation one which should be fixable. Trying to make mmap(anonymous) lightning fast when there is malloc() doesn't really make sense to me. The real question is whether TTM suits the driver writers for use in Linux desktop and embedded environments, and I think so far I'm not seeing enough positive feedback from the desktop side. I actually haven't seen much feedback at all. At least not on the mailing lists. Anyway we need to look at the alternatives which currently is GEM. GEM, while still in development basically brings us back to the functionality of TTM 0.1, with added paging support but without fine-grained locking and caching policy support. I might have misunderstood things but quickly browsing the code raises some obvious questions: 1) Some AGP chipsets don't support page addresses 32bits. GEM objects use GFP_HIGHUSER, and it's hardcoded into the linux swap code. 2) How will user-space mapping of IO memory (AGP apertures) work? Eviction and associated killing / refaulting of IO memory mappings? 3) How do we avoid illegal physical page aliasing with non-Intel hardware? And how are we going to get the kernel purists to accept it when they already complain about WC - UC aliasing? 4) How is VRAM incoporated in the GEM design? How do we map it and keep the mapping during eviction? 5) What's protecting i915 GEM object privates and lists in a multi-threaded environment? 6) Isn't do_mmap() strictly forbidden in new drivers? I remember seeing some severe ranting about it on the lkml? TTM is designed to cope with most hardware quirks I've come across with different chipsets so far, including Intel UMA, Unichrome, Poulsbo, and some other ones. GEM basically leaves it up to the driver writer to reinvent the wheel.. Also wrt the i915 driver it has too many experiments in it, the i915 users need to group together and remove the codepaths that make no sense and come up with a ssuitable userspace driver for it, remove all unused fencing mechanisms etc.. Agreed, but back to the real and to me very important question: If I embark on a new OS driver today and want to use advanced memory manager stuff. Have VRAM and multiple advanced syncing mechanisms. What's my best option to get it into the kernel? Can I hook up driver specific TTM and get it in? /Thomas Dave. /Thomas - 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: TTM merging?
On 5/14/08, Dave Airlie [EMAIL PROTECTED] wrote: I was hoping that by now, one of the radeon or nouveau drivers would have adopted TTM, or at least demoed something working using it, this hasn't happened which worries me, perhaps glisse or darktama could fill in on what limited them from doing it. The fencing internals are very very scary and seem to be a major stumbling block. Aside from the fencing code, I have some othern more general, concerns with respect to using TTM on recent hardware. Although I've raised them before, it was on IRC, not really on the list. The main issue in my opinion, is that TTM enforces most things to be done form the kernel, and how those things should be done: command checking with relocations, fence emission, memory moves... Depending on the hardware functionality available, this might be useless or even counter-productive. Also, I'm concerned about handling chips that can do page faults in video memory. It is interesting to be able to use this feature (which was asked for by the windows guys). For example we could have the ability to have huge textures paged in progressively at the memory manager level. So to me the current TTM design lacks enough flexibility for recent chip features. I'm not saying all of this has to be implemented now, but it should not be prevented by the design. After all, if the memory manager is here to stay, I'd say it needs to be future-proof. Stephane - 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 15850] [i915 i965] glean case blendFunc failed if compiled with USE_SSE_ASM option
http://bugs.freedesktop.org/show_bug.cgi?id=15850 haihao [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from haihao [EMAIL PROTECTED] 2008-05-13 18:56:19 PST --- 4b7d301c94d33394550322768a9d2232087b2d64 -- 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
GEM - the Graphics Execution Manager
On Tue, 2008-05-13 at 21:35 +0100, Dave Airlie wrote: 2) Intel have asked that we don't push i915 support upstream as they believe it isn't ready and as they end up supporting the kernel module in the longer term I cannot go against that without a good reason. I have no other driver to push hence stalled. I'll leave keithp to comment on this further. We've spent the last couple of weeks writing a different manager for the kernel, called 'gem' (for 'graphics execution manager'). It takes the lessons we've learned from TTM and constructs just the API we need to implement the dri_bufmgr interface. On 915, performance for openarena is 50% faster than classic (15.4fps to 23.6fps for a demo Eric recorded), and our favorite benchmark, glxgears, runs 60% faster (551fps to 889fps) The glxgears number is semi-interesting because I think it shows the bandwidth available between CPU and GPU for command execution. Performance for 965 is similar to classic mode, although we're working mostly on gen3 hardware as that's a lot easier to use, so we haven't started taking advantage of the new gem-specific APIs. This code is not complete yet, the biggest missing feature is proper latency-throttling where we'd like to keep the ring nearly empty and pend new requests while the ring executes older ones. We should have that finished up this week, at which point I think the code will be functionally complete. Here's the 'drm-gem.txt' document from the drm-gem branch of my drm repository ( git://people.freedesktop.org/~keithp/drm ). There are parallel drm-gem branches in my mesa and xf86-video-intel repositories. Key features: * Memory is allocated using shmfs; objects not pinned to the GTT are pageable. * Cache synchronization is handled automatically by the kernel, for GPU-GPU object transfers, no ring stall is required. * Objects can be written (using pwrite) from user space. This eliminates most cache effects from clflush as pwrite uses non-temporal stores. * There are no fences exposed for the Intel driver. This document reflects the current status of the implementation. - The Graphics Execution Manager Part of the Direct Rendering Manager == Keith Packard [EMAIL PROTECTED] Eric Anholt [EMAIL PROTECTED] 2008-5-9 Contents: 1. GEM Overview 2. API overview and conventions 3. Object Creation/Destruction 4. Reading/writing contents 5. Mapping objects to userspace 6. Memory Domains 7. Execution (Intel specific) 8. Other misc Intel-specific functions 1. Graphics Execution Manager Overview Gem is designed to manage graphics memory, control access to the graphics device execution context and handle the essentially NUMA environment unique to modern graphics hardware. Gem allows multiple applications to share graphics device resources without the need to constantly reload the entire graphics card. Data may be shared between multiple applications with gem ensuring that the correct memory synchronization occurs. Graphics data can consume arbitrary amounts of memory, with 3D applications constructing ever larger sets of textures and vertices. With graphics cards memory space growing larger every year, and graphics APIs growing more complex, we can no longer insist that each application save a complete copy of their graphics state so that the card can be re-initialized from user space at each context switch. Ensuring that graphics data remains persistent across context switches allows applications significant new functionality while also improving performance for existing APIs. Modern linux desktops include significant 3D rendering as a fundemental component of the desktop image construction process. 2D and 3D applications paint their content to offscreen storage and the central 'compositing manager' constructs the final screen image from those window contents. This means that pixel image data from these applications must move within reach of the compositing manager and used as source operands for screen image rendering operations. Gem provides simple mechanisms to manage graphics data and control execution flow within the linux operating system. Using many existing kernel subsystems, it does this with a modest amount of code. 2. API Overview and Conventions All APIs here are defined in terms of ioctls appplied to the DRM file descriptor. To create and manipulate objects, an application must be 'authorized' using the DRI or DRI2 protocols with the X server. To relax that, we will need to implement some better access control mechanisms within the hardware portion of the driver to prevent inappropriate cross-application data access. Any DRM driver which does not support GEM will return -ENODEV for all of these ioctls. Invalid object handles return -EINVAL. Invalid object names return
[Bug 15881] [i915 i965] glean case api2/fragProg1/texCombine/ vertProg1 failed with assertion failure
http://bugs.freedesktop.org/show_bug.cgi?id=15881 --- Comment #3 from Shuang He [EMAIL PROTECTED] 2008-05-13 22:23:06 PST --- this issue is caused by following commit: author Brian [EMAIL PROTECTED] Wed, 7 May 2008 05:08:51 + (23:08 -0600) committer Brian [EMAIL PROTECTED] Wed, 7 May 2008 05:08:51 + (23:08 -0600) commit df43fb661b2030d9b833a42dd47b8d7bf58d73aa implement full reference counting for vertex/fragment programs Use _mesa_reference_vert/fragprog() wherever we assign program pointers. Fixes a memory corruption bug found with glean/api2 test. -- 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
