On Tue, Jan 20, 2015 at 10:10:57PM -0800, Kristian Høgsberg wrote:
> However, drm_intel_bo_reference/unreference() is showing up on the
> profiles now that relocations are cheaper, but I think the better way
> to make those cheaper is to move the ref count to the public struct
> and make the ref/un
On Wed, Jan 21, 2015 at 10:17:01AM +0100, Daniel Vetter wrote:
> On Tue, Jan 20, 2015 at 10:10:57PM -0800, Kristian Høgsberg wrote:
> > However, drm_intel_bo_reference/unreference() is showing up on the
> > profiles now that relocations are cheaper, but I think the better way
> > to make those chea
On Tue, Jan 20, 2015 at 10:10:57PM -0800, Kristian Høgsberg wrote:
> However, drm_intel_bo_reference/unreference() is showing up on the
> profiles now that relocations are cheaper, but I think the better way
> to make those cheaper is to move the ref count to the public struct
> and make the ref/un
On Tue, Jan 20, 2015 at 10:10:57PM -0800, Kristian Høgsberg wrote:
> On Tue, Jan 20, 2015 at 1:46 PM, Chris Wilson
> wrote:
> > On Tue, Jan 20, 2015 at 12:53:35PM -0800, Kristian Høgsberg wrote:
> >> On Tue, Jan 20, 2015 at 12:42 AM, Daniel Vetter wrote:
> >> > My idea for all this would have be
On Tue, Jan 20, 2015 at 1:46 PM, Chris Wilson wrote:
> On Tue, Jan 20, 2015 at 12:53:35PM -0800, Kristian Høgsberg wrote:
>> On Tue, Jan 20, 2015 at 12:42 AM, Daniel Vetter wrote:
>> > My idea for all this would have been to create a per-thread execbuf
>> > relocation context with a hashtab to ma
On Tue, Jan 20, 2015 at 12:53:35PM -0800, Kristian Høgsberg wrote:
> On Tue, Jan 20, 2015 at 12:42 AM, Daniel Vetter wrote:
> > My idea for all this would have been to create a per-thread execbuf
> > relocation context with a hashtab to map buffer pointers to execbuf index
> > and a bunch of array
On Tue, Jan 20, 2015 at 12:42 AM, Daniel Vetter wrote:
> On Mon, Jan 19, 2015 at 09:45:35PM -0800, Kristian Høgsberg wrote:
>> On Fri, Jan 16, 2015 at 8:23 PM, Daniel Vetter wrote:
>> > On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
>> >> The I915_EXEC_NO_RELOC flag lets us te
On Mon, Jan 19, 2015 at 09:45:35PM -0800, Kristian Høgsberg wrote:
> On Fri, Jan 16, 2015 at 8:23 PM, Daniel Vetter wrote:
> > On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
> >> The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
> >> provide in the validate
On Mon, Jan 19, 2015 at 09:58:55PM -0800, Kristian Høgsberg wrote:
> On Sat, Jan 17, 2015 at 1:49 AM, Chris Wilson
> wrote:
> > On Sat, Jan 17, 2015 at 05:23:59AM +0100, Daniel Vetter wrote:
> >> On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
> >> > The I915_EXEC_NO_RELOC flag
On Sat, Jan 17, 2015 at 1:49 AM, Chris Wilson wrote:
> On Sat, Jan 17, 2015 at 05:23:59AM +0100, Daniel Vetter wrote:
>> On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
>> > The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
>> > provide in the validate list
On Fri, Jan 16, 2015 at 8:23 PM, Daniel Vetter wrote:
> On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
>> The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
>> provide in the validate list entry is what we've used in all relocations
>> to the bo in question.
On Sat, Jan 17, 2015 at 05:23:59AM +0100, Daniel Vetter wrote:
> On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
> > The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
> > provide in the validate list entry is what we've used in all relocations
> > to the bo i
On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
> The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
> provide in the validate list entry is what we've used in all relocations
> to the bo in question. If the bo hasn't moved, the kernel can skip
> relocations
The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
provide in the validate list entry is what we've used in all relocations
to the bo in question. If the bo hasn't moved, the kernel can skip
relocations completely.
Signed-off-by: Kristian Høgsberg
---
intel/intel_bufmgr_gem.
14 matches
Mail list logo