Re: Unmappable VRAM patchset V4
On Mon, Mar 01, 2010 at 01:03:38PM +0100, Thomas Hellstrom wrote: Dave Airlie wrote: On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse jgli...@redhat.com wrote: Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. Hi Dave! My schedule is currently a bit tight. I think the immediate deadlock concerns are met, but I'd to take a deeper look at some things that look a bit suspicious, but I think the overall approach is ok. I'll hopefully be able to do a review on wednesday. /Thomas Thomas any chance to review this ? NVidia patch already need update and i would like to avoid having this bitrot too much. Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unmappable VRAM patchset V4
Jerome Glisse wrote: On Mon, Mar 01, 2010 at 01:03:38PM +0100, Thomas Hellstrom wrote: Dave Airlie wrote: On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse jgli...@redhat.com wrote: Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. Hi Dave! My schedule is currently a bit tight. I think the immediate deadlock concerns are met, but I'd to take a deeper look at some things that look a bit suspicious, but I think the overall approach is ok. I'll hopefully be able to do a review on wednesday. /Thomas Thomas any chance to review this ? NVidia patch already need update and i would like to avoid having this bitrot too much. Cheers, Jerome Jerome, I've reviewed the TTM patch, see previous mail. I'll look at the vmware patch and briefly the other ones as soon as we've sorted out how to address the issues raised in the review. Thanks, /Thomas -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unmappable VRAM patchset V4
On Wed, Mar 17, 2010 at 02:01:47PM +0100, Thomas Hellstrom wrote: Jerome Glisse wrote: On Mon, Mar 01, 2010 at 01:03:38PM +0100, Thomas Hellstrom wrote: Dave Airlie wrote: On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse jgli...@redhat.com wrote: Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. Hi Dave! My schedule is currently a bit tight. I think the immediate deadlock concerns are met, but I'd to take a deeper look at some things that look a bit suspicious, but I think the overall approach is ok. I'll hopefully be able to do a review on wednesday. /Thomas Thomas any chance to review this ? NVidia patch already need update and i would like to avoid having this bitrot too much. Cheers, Jerome Jerome, I've reviewed the TTM patch, see previous mail. I'll look at the vmware patch and briefly the other ones as soon as we've sorted out how to address the issues raised in the review. Thanks, /Thomas Will redo a patch tomorrow to try to address issue you pointed. Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unmappable VRAM patchset V4
Dave Airlie wrote: On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse jgli...@redhat.com wrote: Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. Hi Dave! My schedule is currently a bit tight. I think the immediate deadlock concerns are met, but I'd to take a deeper look at some things that look a bit suspicious, but I think the overall approach is ok. I'll hopefully be able to do a review on wednesday. /Thomas -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unmappable VRAM patchset V4
On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse jgli...@redhat.com wrote: Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Unmappable VRAM patchset V4
Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Unmappable VRAM patchset V4
Correct dereferencing of null ptr in path 2,3,4. Still doing testing on radeon but so far beside this null ptr it seems stable. Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
