:do_wait_request] *ERROR* i915_do_wait_request returns -11
(awaiti
ng 23347 at 23343, next 23348)
Ping?
Generally we need the i915_error_state from debugfs when diagnosing gpu
hangs. Can you please attach that one?
Thanks, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
lots of output in it.. I can grab it
after a clean reboot if that helps.
I've taken a quick look and nothing jumps out immediately.
Anything else I can provide?
Can you attach the full dmesg, please. And are you using any special i915
module options?
Yours, Daniel
--
Daniel Vetter
Mail: dan
And warn loudly in case people want to use it. Too many tester report
gpu hangs on irc and we rootcause this ...
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
configure.ac |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index
On Mon, Nov 28, 2011 at 03:17:09PM -0800, Jose Fonseca wrote:
- Original Message -
And warn loudly in case people want to use it. Too many tester report
gpu hangs on irc and we rootcause this ...
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
If you're doing this then why
into here. I'll see what makes a good fit and shows best what
awesome stuff is currently going on in opens source graphics.
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
mesa-dev mailing list
mesa-dev
took us a few attempts to put that crazy pciid into the
right tables in the kernel/ddx/mesa - originally we've marked it as gen3
until someont tried to actually use it. Marketing and production
differention win again :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
with latest 3.8-rc kernels might be good - we've just merged a
few workaround patches for snb, which reportedly fix some hangs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
On Tue, Feb 05, 2013 at 10:40:28PM +0100, Martin Steigerwald wrote:
Am Dienstag, 5. Februar 2013 schrieb Daniel Vetter:
On Sat, Feb 02, 2013 at 09:22:55PM +0100, Martin Steigerwald wrote:
About these messages: Uhm, bingo:
merkaba:~ zgrep -i GPU hung /var/log/kern.log*
/var/log
, slice);
} else {
intel_miptree_map_gtt(intel, mt, map, level, slice);
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer
://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
need to have a proper interface for
userspace to figure this out. And snoopable bos obviously need a separate
cache, otherwise we'll drown in clflush. On the patch:
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 23
;
return I915_TILING_NONE;
}
--
1.8.1.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
On Tue, Apr 09, 2013 at 01:17:39AM +0200, Daniel Vetter wrote:
On Mon, Apr 08, 2013 at 07:27:38PM -0700, Kenneth Graunke wrote:
In the past, we preferred X-tiling for color buffers because our BLT
code couldn't handle Y-tiling. However, the BLT paths have been largely
replaced by BLORP
with a i830_dri.so -
i915_dri.so symlink and the ddx should start to ask for the i830 dri on
gen2.
Back in the days when I didn't just have little, but provable zero clue
I've had some amusement around that on my i855gm trying to use i915g ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel
and 64b
when Y-tiling is possible?
Otoh only pre-gen6 would care, so meh. Either way
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
- if (ALIGN(mt-total_width * mt-cpp, 512) = 32768) {
+ if (ALIGN(minimum_pitch, 512) = 32768) {
perf_debug(%dx%d miptree too large to blit, falling
://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
don't remember having any trouble like this before.
This one here maybe?
https://bugs.freedesktop.org/show_bug.cgi?id=63914
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev
on the kernel side.
Things are solved on the kernel side now I think, and prime fixes are
trickling down to all stable releases atm. So I don't think you need any
workarounds and we can just enable prime buffer passing in the next mesa
release.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
-eg_image step still gives a useful piece of information to
users.
Since this sounds like a spec question cc'ing all the people from the
original dma_buf_import spec discussions.
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
patches for backporting, there's no
burden on developers to keep track of patches which should get nominated
after some testing and still there's a reasonable chance that crap doesn't
land in the stable branch.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
,
brw-shader_time.bo, 0,
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
, and they can happen even if mesa _never_ access the
bo from the gpu with cached mocs settings or with the cpu.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev
is directly driven by vm pressure.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa
in _mesa_ClientWaitSync (if the
driver sets syncObject-Status correctly). So I guess the current
kernel code should work as-is and only the libdrm interface needs some
colour adjustments around the timeout parameter.
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
libdrm doesn't make much sense imo.
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
param and fallback for older kernels
v3: only doing getparam at init
prototypes now have a signed input value
v4: update comments
fall back to correct polling behavior with new userspace and old kernel
Cc: Eric Anholt e...@anholt.net
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off
-StatusFlag = 1;
drm_intel_bo_unreference(sync-bo);
sync-bo = NULL;
--
1.7.10.3
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
in this function instead. As Daniel pointed out, the polling
case (timeout == 0) should also return -ETIME.
Cc: Eric Anholt e...@anholt.net
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
intel
) is executed instead of
glClear(DEPTH)/glClear(STENCIL).
Woot, nice catch - iirc this problem elluded me for about a year, i.e.
since I've enabled hw clears.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Do you have commit access or should I do that?
Yours, Daniel
---
src/gallium/drivers/i915
patches directly and only applied the minimal change to get rid of
object-context_id.
Please commit the i-g-t testcase so that qa can start testing this aspa.
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
mesa-dev
grossly
oversized) works around the issue. These patches here don't fix this major
issue, but at least a few other things.
Cheers, Daniel
Daniel Vetter (3):
i965: tackle the occlusion query pipe control mess
i965: we want 64bit writes for depth count
i965: adjust gen6+ timestamp
- Separate out the depth stall from the depth count write, workarounds
say that a depth stall needs to be preceeded with a non-zero
post-sync op.
- Implement the cs stall workaround like the kernel does.
I've hoped that this would fix a occlusion query issue on snb, but
alas, it doesn't seem
... and the hardware seems to take the lenght of the pipe control
command to indicate whether the write is 64bit or 32bit. Which makes
sense for immediate writes.
I've discovered this by writing a pattern into the query object bo and
noticing that the high 32bits are left intact, even on those
Similar treatment to the depth count pipe_control writes
- Add the CS_STALL workaround, timestamp writes are non-zero post-sync
ops, too.
- Also ensure that we write the full 64bits by using the 5 dword long
variant of pipe_control.
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 32
On Sun, Jul 01, 2012 at 07:59:56PM -0700, Kenneth Graunke wrote:
On 06/26/2012 07:28 AM, Daniel Vetter wrote:
... and the hardware seems to take the lenght of the pipe control
command to indicate whether the write is 64bit or 32bit. Which makes
sense for immediate writes.
I've
On Sun, Jul 01, 2012 at 08:10:49PM -0700, Kenneth Graunke wrote:
On 06/26/2012 07:28 AM, Daniel Vetter wrote:
Similar treatment to the depth count pipe_control writes
- Add the CS_STALL workaround, timestamp writes are non-zero post-sync
ops, too.
- Also ensure that we write the full
... and the hardware seems to take the lenght of the pipe control
command to indicate whether the write is 64bit or 32bit. Which makes
sense for immediate writes.
I've discovered this by writing a pattern into the query object bo and
noticing that the high 32bits are left intact, even on those
- Separate out the depth stall from the depth count write, workarounds
say that a depth stall needs to be preceeded with a non-zero
post-sync op.
- Implement the cs stall workaround like the kernel does.
I've hoped that this would fix a occlusion query issue on snb, but
alas, it doesn't seem
Similar treatment to the depth count pipe_control writes
- Add the CS_STALL workaround, timestamp writes are non-zero post-sync
ops, too.
- Also ensure that we write the full 64bits by using the 5 dword long
variant of pipe_control.
v2: Implement |(5-2) suggestion from Kenneth Graunke.
---
PIPE_CONTROL has variable length, depending upon gen and whether we
write out 32bit or 64bit. So make this explicit.
Suggested by Kenneth Graunke.
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 22 +++---
src/mesa/drivers/dri/i965/gen6_vs_state.c |2 +-
need a CS stall, which needs a stall at scoreboard.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
In my understanding of Bspec (haven't done any experiments on hw) we need
to set the depth stall bit on the pipe_control
On Wed, Aug 08, 2012 at 09:41:44AM +0200, Daniel Vetter wrote:
On Tue, Aug 07, 2012 at 04:05:33PM -0700, Kenneth Graunke wrote:
Separate out the depth stall from the depth count write. Workarounds
say that a depth stall needs to be preceeded with a non-zero post-sync
op (in this case
Vetter daniel.vet...@ffwll.ch
Cc: Eric Anholt e...@anholt.net
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
v2 lsooks good to me now.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
the monotonic clock, leading to nice unified timestamps accross all things
linux media.
Hence I think pipe queries should do the same, just for consistency.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More in line with other intel drivers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_resource.h |4 ++--
src/gallium/drivers/i915/i915_resource_texture.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src
Not using the gtt is considered harmful for performance. And for
partial uploads there's always drm_intel_bo_subdata.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/winsys/i915/drm/i915_drm_buffer.c | 16 ++--
src/gallium/winsys/i915/drm/i915_drm_winsys.h
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_reg.h|2 ++
src/gallium/drivers/i915/i915_screen.c |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_reg.h
b/src/gallium/drivers/i915
].
i915g is still in a very sorry state:
- crashes with BadDrawable on GLXFBconfig changes (and desdruction) with
openaren.
- hangs the chip after a few minutes.
- ...
Anyway, I've decided to submit the first batch of patches. Comments and
reviews highly welcome.
Thanks, Daniel
Daniel Vetter (13
The drm winsys only ever handles one gem memory manager. Rip out
the unnecessary complication.
---
src/gallium/winsys/i915/drm/i915_drm_batchbuffer.c |2 +-
src/gallium/winsys/i915/drm/i915_drm_buffer.c |9 ++---
src/gallium/winsys/i915/drm/i915_drm_winsys.c |6 +++---
Different kernels have different restrictions for tiled buffers.
Hence use the libdrm abstraction to calculate the necessary
stride and height alignment requirements.
Not yet used.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_winsys.h|8
This way relaxed fencing is handled by libdrm. And buffers _can't_
ever change their tiling.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_resource_texture.c | 16 ++--
src/gallium/drivers/i915/i915_winsys.h |9 -
src
Wire up a fenced parameter, switch all relocations to _FENCED
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_batch.h |5 ++-
src/gallium/drivers/i915/i915_batchbuffer.h|4 +-
src/gallium/drivers/i915/i915_blit.c
Also change the vbo reloc to unfenced - tiled vbos are not a great idea ;-)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_context.h|3 +--
src/gallium/drivers/i915/i915_reg.h|2 ++
src/gallium/drivers/i915/i915_state_emit.c | 12
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/drivers/i915/i915_reg.h |5 -
src/gallium/drivers/i915/i915_state_sampler.c |3 +--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/i915/i915_reg.h
b/src/gallium/drivers
doing so).
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Jesse,
On Sat, Jan 08, 2011 at 03:10:03PM -0800, Jesse Barnes wrote:
On Sat, 8 Jan 2011 16:02:09 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
I've been tracking down an annoying flickering problem on intel hw
that completely disappears with vblank_mode=0. Some add-hoc tracing
all
of
||?
No, because irb is NULL, so the following references would segfault.
The condition checks for !irb, so with the we will deref irb only if
it is NULL. I haven't checked the code and generally got squat clue about
all this ...
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0
that swizzling is enable, but it isn't. The
kernel commit that fixes this for backport to pre-v3.2 is
commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon Sep 12 20:49:16 2011 +0200
drm/i915: fix swizzling on gen6+
But if the kernel doesn't lie
*/
if (dims != 2 || !intel_blit_texsubimage(ctx, texImage,
xoffset, yoffset,
--
1.7.12
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel
On Thu, Sep 13, 2012 at 04:22:20PM +0300, Chad Versace wrote:
On 09/11/2012 10:40 PM, Daniel Vetter wrote:
Only quick read-through but I'd have expected a has_llc check in there
- if vlv is anything like the previous platforms wc gtt will be much
faster there.
I'm not too familiar
). Or something else.
To make the intel roundup complete: Chris, can I volunteer you to give
another stab at an updates from flatland talk?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
1.7.11.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Vetter daniel.vet...@ffwll.ch
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-checking the code. On the other hand, that
part is broken, it needs a
tex-tiling = I915_TILE_NONE;
and perhaps some check that width == height == 64 indeed holds. Then
move it out as the first if clause and it'd start to make sense ...
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0
On Mon, May 2, 2011 at 8:40 PM, Marcin Slusarz marcin.slus...@gmail.com wrote:
On Mon, May 02, 2011 at 03:11:00PM +0200, Daniel Vetter wrote:
On Mon, May 2, 2011 at 2:56 PM, Benjamin Franzke
benjaminfran...@googlemail.com wrote:
I think in i915g the CURSOR flag should be used
the pixel format to gbm so we can generate buffers with that format.
Creating 10bpc rgb framebuffers also works with the old addfb ioctl, same
for rbg565 and rgb555. Heck even c8 palette mode works ;-) Just so you
don't unduly restrict the wayland/weston support here ...
Cheers, Daniel
--
Daniel Vetter
:
this-brw_surfaceformat = BRW_SURFACEFORMAT_R16_UNORM;
break;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
-by: Daniel Vetter daniel.vet...@ffwll.ch
It's a bit hairy how the outermost blt code needs to check the depth
stuff, I'd have prefered to keep that logic in one place. But bubbling
that error up the layers looks like a pain, blorp has other similar
conditions already and the code seems
helper used by the gen6 queryobj code.
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
b/src
.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 07, 2013 at 04:23:12PM -0800, Ian Romanick wrote:
On 11/07/2013 01:33 PM, Daniel Vetter wrote:
On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
+ /* Once a batch uses more than 75% of the maximum mappable size, we
+ * assume that there's some
://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Nov 11, 2013 at 11:03:49AM -0800, Ian Romanick wrote:
On 11/09/2013 02:44 AM, Daniel Vetter wrote:
On Fri, Oct 11, 2013 at 03:10:14PM -0700, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa
.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Daniel Vetter dan...@ffwll.ch
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/intel_screen.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
On Mon, Nov 11, 2013 at 01:45:43PM -0800, Ian Romanick wrote:
On 11/11/2013 01:35 PM, Daniel Vetter wrote:
On Mon, Nov 11, 2013 at 11:19:07AM -0800, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Systems with little physical memory installed will report less than
2GiB
a few questions I wanted to throw out there for consideration,
current approach looks fine to me. I've read through the entire pile of
patches, so
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
on the series. Whatever that's worth ;-)
Cheers, Daniel
+
+/**
+ * Called at the end of every render
, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard kei...@keithp.com wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the kernel as drm_fourcc.h, and that
one is part of the userspace ABI
the different projects anyway, so meh.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
a small comment saying that the kernel lies. Or just remove it. Either
way:
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Aside: I think drm is the only subsystem that goes out of it's way to
ensure a unique relationship between dmabuf and other handles and
underlying objects. If you throw
but also no false positive
compiler warnings, even in release builds.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
checks whether the write lands) for gen67, this is
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri
(and MI_FLUSH_DW, too) have a
stern w/a notice on all gen6+ generations that bit5 of the target address
must be cleared. I haven't checked existing users, but these here seem
safe. So
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 15 +--
1
() intel_batchbuffer_cached_advance(brw);
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
On Fri, Dec 13, 2013 at 10:04:53AM -0800, Kenneth Graunke wrote:
On 12/13/2013 09:28 AM, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits
do that dance in reverse if we want to have a pci id based
lookup.
Anyway I've never read through the loader code, just figured it won't
hurt if I drop my uninformed opinion ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Dec 16, 2013 at 11:19:56AM -0800, Eric Anholt wrote:
Daniel Vetter dan...@ffwll.ch writes:
On Sat, Dec 14, 2013 at 3:33 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
On 11/18/2013 12:58 PM, Emil Velikov wrote:
On 18/11/13 01:08, Keith Packard wrote:
libudev doesn't have
to consult the
I915_PARAM_HAS_ALIASING_PPGTT driver param. If it is set then you should
use ppgtt as the address space selector. This will even hold for full
ppgtt (so a better name would be USES_PPGTT_FOR_EXECBUF, but abi and all
that).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel
) only has 512 MB of aperture ... Also going this
high runs the risk that you fool up with fragmentation, but meh.
You'd need to get at bufmgr_gem-gtt_size somehow. At least the current
code is safe for address spaces 4G.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev
On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
Hi,
2014-03-14 22:52 GMT+01:00 Daniel Vetter dan...@ffwll.ch:
On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauchesne wrote:
This is a follow-up to:
http://lists.freedesktop.org/archives/mesa-dev/2014-March/055742
On Wed, Mar 19, 2014 at 7:30 AM, Gwenole Beauchesne gb.de...@gmail.com wrote:
2014-03-15 12:28 GMT+01:00 Daniel Vetter dan...@ffwll.ch:
On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
Hi,
2014-03-14 22:52 GMT+01:00 Daniel Vetter dan...@ffwll.ch:
On Fri, Mar 14, 2014
for the kernel team.
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
poking people to look at this for years. too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
If a GPU
client uses only prelocations, the relocation process can
1 - 100 of 325 matches
Mail list logo
