There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_agpsupport.c | 40 +++--
drivers/gpu/drm/drm_memory.c | 12
for this is a rather gross amount of fragile code duplication
between these two parts of the kernel intel graphics driver.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_agpsupport.c |7 ---
drivers/gpu/drm/i915/i915_gem.c |8
include/drm/drmP.h
some WARN_ONs in i915_write_fence_reg like I've done for the i830
case (using the right limits).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449
Tested-by: Alexander Lam lambchop...@gmail.com
Cc: sta...@kernel.org
---
drivers/gpu/drm
Hi Jesse,
This is something I've stumbled upon while crawling through code. Passing
a fifo line size instead of a latency is surely not what's ment to happen.
Can you please take a look? I think the below patch makes somewhat sense.
Yours, Daniel
---
drivers/gpu/drm/i915/intel_display.c |4
-agp.o - drivers/char/agp/intel-agp.o
dependency dropped.
Instead of renaming intel-agp.c I've simply created a new module out
of intel-gtt.c. Renaming intel-agp.ko to something else is not an option
for it will surely kill someones boot process.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
of ten :(
Yours, Daniel
Daniel Vetter (1):
i830 uxa: track fence reg usage exactly
src/i830.h | 13 ++-
src/i830_batchbuffer.c |2 +
src/i830_driver.c | 32
src/i830_render.c | 12 +++---
src/i830_uxa.c | 95
in put_fence. No functional
change because put_fence checks whether there is actually a
fence allocated, so the put_fence in adjust_fencing won't harm.
But IMHO the code makes slightly more sense this way around.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h
. Spotted
by Chris Wilson.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 30 +-
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 023f4db
and merge for -next.
Applies on top of my avoid-bo-reuse-related-stalls series (because that
introduced yet another wasteful 32bit wide boolean).
Thanks, Daniel
Daniel Vetter (2):
drm/i915: move fence lru to struct drm_i915_fence_reg
drm/i915: combine all small integers into one single bitfield
This saves a whooping 8 dwords. Zero functional changes. Because
some of the refcounts are rather tightly calculated, I've put
BUG_ONs in the code to check for overflows.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 87
drm-intel-next, too.
Yours, Daniel
Daniel Vetter (4):
agp/intel-gtt: steal the last gtt page
drm/i915: add locking around chipset flush
agp/intel-gtt: check cache-coherency on i830 class chipsets
agp/intel-gtt: extract mch buffer flush in i830 chipset flush
drivers/char/agp/intel-gtt.c
it only contains this
single define. But I've already noticed quite some code duplication
between the intel-agp and the i915 drm module. The idea is that this
new header file can be used to share some code between these two
modules.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char
My cache coherency checker for i8xx chipsets will make cache flushes
stateful. Therefore add some locking around the only caller that had
none. This is not a fast-path, anyway, so it won't hurt for the other
chipsets.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915
Just a small clean up. The real fix will add tons of code here,
so it's nice to shrink the function a tad bit, first.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff
.
Please (re-)apply to -next.
Thanks, Daniel
Daniel Vetter (1):
drm/i915: combine all small integers into one single bitfield
drivers/gpu/drm/i915/i915_drv.h | 75 +-
drivers/gpu/drm/i915/i915_gem.c |5 +++
2 files changed, 54 insertions(+), 26 deletions
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi all,
On Fri, May 14, 2010 at 11:51:14AM +0200, Daniel Vetter wrote:
So please explain the technical reasons we need this rather complex beast
of code in the kernel?
Ok, I owe you my apologies (and a beer). I've read through the HD docs and
it looks like bsd decoding for avc/vc1 can't
. And if you try to, your users will get the
pitchforks and scream bloody murder trying to get you ;) So we need to get
these patches right (at least the semantics of the interface) beforehand.
Thanks
Zou Nan hai
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
i915 needs this.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
include/linux/list.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index 8392884..21cdd99 100644
--- a/include/linux/list.h
+++ b/include
Only ever assigned, never used.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c |4 +---
drivers/gpu/drm/ttm/ttm_bo.c |6 --
drivers/gpu/drm/ttm/ttm_bo_util.c |2 --
include/drm/drm_mm.h |1 -
4 files changed, 1
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_mm.c | 45 -
1 files changed, 0 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index b75eb55..a5a7a16 100644
--- a/drivers
There are already two copies of this logic. And the new scanning
stuff will add some more. So extract it into a small helper
function.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_mm.c | 71 ++
1 files changed, 34
Yeah, I've kinda noticed that fl_entry is the free stack. Still
give it (and the memory node list ml_entry) decent names.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_mm.c | 72 ++---
include/drm/drm_mm.h | 11
object, so
move the unbind call into the helper function that scans for the object
to be evicted, too. And adjust its name.
No functional changes in this patch, just preparation.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 65
approach by i915 (scan the lru for a object large enough to contain
the new object). It's also more efficient than the current approach used
by ttm (uncoditionally evict objects from the lru until there's enough
free space).
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm
On Wed, May 19, 2010 at 11:25:07AM +0200, Jerome Glisse wrote:
On Tue, May 18, 2010 at 11:11:45PM +0200, Daniel Vetter wrote:
Only ever assigned, never used.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
NAK
private was to be use when doing range restricted allocation
somehow
send-email --to 'b...@bla.com' --cc 'f...@bar.com' *.patch [--dry-run]
sends them away. Use --dry-run to check first that git does the right
thing with your patches.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
that and doing regression and duration
tests over the patch. I will sent out V2 tomorrow.
Ok, I'll wait till v2 arrives on intel-gfx with reviewing your patches.
Thanks
Zou Nan hai
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
On Tue, Jun 01, 2010 at 05:17:45PM +0800, Xiang, Haihao wrote:
On Fri, 2010-05-28 at 22:04 +0800, Daniel Vetter wrote:
On Tue, May 25, 2010 at 01:06:50PM +0800, Xiang, Haihao wrote:
This interface is the same as drm_intel_bo_alloc except the allocated
size isn't rounded up, so it bypasses
enabled
https://bugzilla.kernel.org/show_bug.cgi?id=15664
v2: Daniel Vetter reminded me that kernel space programming is never easy.
We cannot simply spin to clear the pending signal and so must deferred
the freeing of the object until later.
v3: Run from the top level retire requests.
Signed
On Wed, Aug 04, 2010 at 08:57:26PM +0200, Daniel Vetter wrote:
On Wed, Aug 04, 2010 at 03:36:30PM +0100, Chris Wilson wrote:
Incorporates a similar patch by Daniel Vetter, the alteration being to
report the current busy state after retiring.
Woot, nice idea to exactly preserve the semantics
Add a new path for 2nd gen chips that uses the commands for i81x
chips (where public docs do exist) augmented with the plane bits
from i915. It seems to work and doesn't result in a black screen
like before.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: sta...@kernel.org
---
drivers
On Wed, Aug 04, 2010 at 08:26:07PM +0100, Chris Wilson wrote:
v2: Add the interrupt status and address.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
--
Daniel Vetter
Mail: dan...@ffwll.ch
available.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
of the things on my idea for drm/i915 projects:
To unify the overlay/display plane pageflip support code.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
/loop
https://bugs.freedesktop.org/show_bug.cgi?id=28478
v2: Attempt to clarify the logic and order of eviction through the use
of comments and macros.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter dan...@ffwll.ch
One small nitpick below.
int
. Think frontbuffer rendering - that's at least how I've tracked
it down.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
and tiling_mode.
Whatever, current code seems to work.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sun, Aug 08, 2010 at 02:24:11PM +0200, Daniel Vetter wrote:
In conclusion I think we need an if (IS_SNB(dev)) that sets dword 0, bit
22 to 1 and ensures that dword 2, bit 0 is zero. For the rest of of the
IS_I965G branch we might as well write 0 instead of pitch and tiling_mode.
I've played
) supported.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28318
Cc: sta...@kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu
separate out the non-gem ums driver and get rid of the fake agp
driver for kms completely somewhen later.
Comments, flames, ideas highly welcome.
Yours, Daniel
daniel Vetter (23):
agp/intel: split out gmch/gtt probe, part 2
agp/intel: make intel-gtt.c into a real source file
intel-gtt
kill 2 out of the three Ironlake mobile entries that
only differed in host bridge pci id.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-agp.c | 187 +
drivers/char/agp/intel-gtt.c | 116 ++
2 files
Add a few definitions to it that are already shared and that will
be shared in the future (like the number of stolen entries).
No functional changes in here.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c| 42
When the intel-gtt code now longer depends on agp, we cannot rely
on this. So store a local reference in intel-gtt.c.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 69 +++---
1 files changed, 38 insertions(+), 31
, this will grow until it contains
the complete init sequence starting from the call to gtt_mappable_entries.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 83 --
1 files changed, 64 insertions(+), 19 deletions(-)
diff --git
First simple step towards a more generic initialization. This
is needed to disentangle the agp stuff from the stuff that is
actually needed by drm/i915.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 12 ++--
1 files changed, 6 insertions(+), 6
This somewhat aligns it with the version in drm/i915/i915_dma.c.
Changes:
- s/gtt_entries/stolen_size
- track overhead entries in a separate var (the effective gtt size
calculation will be extracted later on).
- subtract the overhead at the end instead of in each clause.
Signed-off-by: Daniel
This uses the new mappable gtt size detection from the previous patch.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 77 +-
1 files changed, 24 insertions(+), 53 deletions(-)
diff --git a/drivers/char/agp/intel
The detection function in drm/i915/i915_dma.c works without it, so
drop it here, too. All the values are distinct, anyway.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 42 --
1 files changed, 8 insertions(+), 34
in intel_gtt_total_size for later use.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 136 ++
1 files changed, 72 insertions(+), 64 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 08428d5
Same idea as INTEL_INFO from drm/i915. This
- reduces the dependancy on agp_driver
- stops the what-does-IS_I965G-mean confusion (here it's just gen4, in
drm/i915 it's gen =4)
- further prepares the separation of the fake agp driver from the rest.
Signed-off-by: Daniel Vetter daniel.vet
Slight reordering of the init sequence required.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 58 ++---
1 files changed, 9 insertions(+), 49 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp
This way around this can be extracted into common code.
Also use a common cleanup function (and give it a generic name).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 41 +++--
1 files changed, 23 insertions(+), 18
Also move the Sandybdridge size detection into gtt_total_entries, like
the rest.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 75 +++---
1 files changed, 34 insertions(+), 41 deletions(-)
diff --git a/drivers/char
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 70 +++--
1 files changed, 26 insertions(+), 44 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index f4308d3..0ebb76a 100644
Slightly reordered sequence was necessary. Also don't set
agp_bridge-gatt_bus_addr anymore. Only used by generic agp helper
functions, hence unnecessary for the intel fake agp driver.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 83
by the generic agp code.
- filling the whole gtt with scratch_page ptes is not yet consolidated -
this needs abstracted pte handling, first.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 60 ++---
1 files changed, 15
The only difference between i915 and i965 was the calculation of the
gtt address. So merge these two paths into one. Otherwise the same
changes as in the i830 setup consolidation.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 154
Use the detection from intel-gtt.ko instead. Hooray!
Also move the stolen mem allocator to the other gtt stuff in dev_priv-mem.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c|6 ++
drivers/gpu/drm/i915/i915_dma.c | 187
and
definitely conflict against newer stuff.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
looked like - it didn't
seem worth the effort for just 2 ringbuffers, but with 5 rings it's a
different story. And there was enough other stuff going on, so that's why
I haven't seen them through and pushed this. But I think you get the idea.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41
://cgit.freedesktop.org/~danvet/drm/
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
and teardown.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 81 +-
1 files changed, 64 insertions(+), 17 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 9cb7c98..af920b5
And put it to use in the gtt configuration code that writes
the scratch page addr in all gtt ptes. This makes intel_i830_configure
generic, hence rename it to intel_fake_agp_configure.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 41
Beef up the generic version to support dmar. Otherwise like for the i830.
v2: Don't try to DMA remap on resume for already remapped pages.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 60 ++---
1 files changed, 49
Like before, but now with the added bonus of being able to kill
quite a bit of no-longer useful code (the old dmar support stuff).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 144 +++---
1 files changed, 8 insertions
Like for the i915.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 8273b2b..225b791 100644
That indirection mess can now go. Add a dummy i81x gtt_driver to
avoid a NULL pointer check.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 105 +
1 files changed, 13 insertions(+), 92 deletions(-)
diff --git
This is the last differentiator between the different fake agp drivers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers
DMA remapping was only used by the intel-gtt driver. With that
code now folded into the driver, kill the agp generic support for
it.
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/agp.h |3 ---
drivers/char/agp/generic.c |8
The old code didn't clean up the i830 chipset flush page. And it
looks nicer.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 39 +++
1 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/char/agp
the complete area for the GGTT.
Unfortunately the graphics core on G33/Pineview can't cope with really
large GTTs and the BIOS usually enables the maximum of 512MB. So
don't bother with maximizing the GTT on these platforms.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char
sequence.
- Fix i855 cache coherency. All these gtt optimizations only made things
worse :(
As usual, comments, flames, highly welcome. Wrt merging I think it'd be
easiest if this goes in via d-i-n completely.
Yours, Daniel
Daniel Vetter (15):
intel-gtt: drop dcache support for i830 and later
i830_check_flags already disallows it, so no need to implement it
in the write_entry function. Seems to be a remnant from i810 support.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff
Used for the now dead agp type_to_mask stuff.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 8122aca..b677713
Initialization is still done with the old code with a few
added things sprinkled in to make the intel_fake_agp helper
functions work.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 152 +-
1 files changed, 60
Still a separate agp_bridge_driver because of the i81x-only
dedicated vram support.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 197 +++---
1 files changed, 71 insertions(+), 126 deletions(-)
diff --git a/drivers
... and a few other defines.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c|5 -
drivers/gpu/drm/i915/i915_gem.c |1 -
include/drm/intel-gtt.h | 12
include/linux/intel-gtt.h | 20
4 files
No longer used.
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_agpsupport.c |6 --
include/drm/drmP.h |1 -
2 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b
this wastes, anyway.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |4
drivers/gpu/drm/i915/i915_gem.c |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
The intel drm calls the chipset functions now directly. Userspace
never called the corresponding ioctl, hence it can be killed, too.
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/agp.h |1 -
drivers/char/agp/compat_ioctl.c
Its only user, intel-gtt.c is now gone.
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/generic.c | 20
include/linux/agp_backend.h |1 -
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers
paranoid and flush the chipset cache after restoring gtt
mappings.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-agp.c|5 ---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_drv.c |1 +
drivers/gpu/drm/i915/i915_drv.h |3
Just some minor shuffling to get rid of any agp traces in the
exported functions.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c | 120 --
include/drm/intel-gtt.h | 12
2 files changed, 80 insertions
No more drm_*_agp in i915_gem.c!
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 28
3 files changed, 33
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |9 +++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 63 --
2 files changed, 50 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu
don't count on me fixing them ;)
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
in the command stream), the fbo texture renders all
black in fbo_firecube. Relocating without NEED_FENCE works flawless.
Latest -linus seems to be affected, too.
This is just fyi, I have currently no clue what's going on and I'm still
investigating.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41
. But
I've been (very) slowly moving towards this in the past few months. Don't
hold your breath, though.
Meanwhile Chris Wilson's shadowfb support should give you Xv accel +
reasonable fast 2d (cpu-rendered, but the gpu was never really faster for
2d on these chips, anyway).
-Daniel
--
Daniel Vetter
to be an existing thing already available. I'm still
fighting the fallout from the incoherent multiple rings introduction and I
just don't want to repeat such a goof-up.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel
Hi Ben,
Am Mi, 29.12.2010, 05:03, schrieb Ben Widawsky:
There is no tie in to multiple ringbuffer support. A client may allocate
a context for all ringuffers, or one for each ringbuffer. I too must
figure out if this is relevant to anything but the graphics engine.
I've been simply thinking
;) My idea of a special
reloc type is probably not the cleanest (hm, slight understatement here ;)
and could need some improvement. Anyway, I'll wait and see what the real
use-case looks like. My arguments feel too hand-waivy already ...
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile
is
probably wishful thinking.
Just my 2 (constantly changing) cents on this. Anyway, you've thought much
more about this than me, so I expect you to shoot this down in a
half-sentence ... ;)
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
(in gem - iirc agp uses it). I just think it's confusing to limit the
general dma mask and continue to happily map pages above 4G.
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx
, essentially to keep in line
with the existing work-around for broken overlay reg files on gen2.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
looks fixed-length and
the length = Total Length - 2 blurb is standard for all multi-word
commands.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Fri, Mar 18, 2011 at 08:02:10AM +, Chris Wilson wrote:
... even though it was disabled. A mistake in the handling of fence reuse
caused us to skip the vital delay of waiting for the object to finish
rendering before changing the register.
Reviewed-by: Daniel Vetter daniel.vet
).
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Ah, this patch addresses my update label comment ;) Otherwise I think
tracking fences more as independent objects definitely results in clearer
semantics. A tiny nitpick below.
@@ -2647,9 +2638,13 @@ i915_gem_object_get_fence(struct
On Fri, Mar 18, 2011 at 10:35:17PM +, Chris Wilson wrote:
Whenever we finish reading an object through a fence, for safety we
clear any GPU read domain and so invalidate any TLBs associated with
the fenced region upon its next use.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
1 - 100 of 22396 matches
Mail list logo
