On Tue, Mar 29, 2016 at 10:00:00AM -0400, Rob Clark wrote:
> On Tue, Mar 29, 2016 at 4:41 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> > On Sat, Mar 26, 2016 at 07:44:58PM -0400, Rob Clark wrote:
> >> On Sat, Mar 26, 2016 at 7:09 PM, Stéphane Marchesin
> >> <
one piece. Your also have to consider things like
> > alignment and format restrictions for video decode for example. These can be
> > different from 3d so you need some knowledge of the video engine for
> > example. Ditto with everything else.
>
> hmm, admittedly I'm used to think of gpu as the most restrictive thing..
>
> But maybe to start with we don't have to solve all the world's
> problems.. maybe it is good enough to do a reference gbm_gralloc which
> works in the common cases.. SoC vendors can still replace it with
> their own thing when the generic one doesn't fit their needs. Going
> from "everyone has their own implementation" to "some have their own
> implementation" seems like forward progress.
>
> At least then we can get to something that works for all the mesa
> drivers and at least a reasonable subset of everyone else..
At least with video I thought the Grand Android Plan was to switch over to
v4l? Maybe we just need to add/query some v4l apis to figure out what's
needed for a basic gralloc that works everywhere. There's still the
question of where to allocate stuff, but maybe a simple heuristics like
assuming that display > v4l > gpu wrt placement constraints (e.g.
allocating from cma or not) should be good enough? Maybe with an optional
fallback to some ION heap for some shared buffers, there's a todo
somewhere about that.
Just throwing out my thoughts, I agree that starting out with a gralloc
that's good enough for display+gpu sounds like a solid plan.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
akes sense if you e.g. have some 2d blitter on
the display block and a 3d gpu and want to make them one thing (and use
the blitter to shuffle bytes around for uploads). Wrt the internal API I'm
not concerned too much, since in the end all that coordination is the
exact same thing we need to add for compositor/client communication too.
They need to agree on what is most suitable as the frontbuffer format and
how/where to allocate it, otherwise you'll suffer tons of unnecessary
copies. In short we need much more powerful "what buffers can you
support/prefer" interfaces anyway, not just for kms/gpu dual drm device
support in gbm. And I actually think prototyping those in gbm is a great
idea, gets rid of the wayland/X proto complexities.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruilin
RAM_REVISION 32
> #define I915_PARAM_SUBSLICE_TOTAL 33
> #define I915_PARAM_EU_TOTAL 34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN 37
>
> typedef struct drm_i915_getparam {
> int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
> #define
onstant GTT size as it also computes addition information not
> used here and has the side-effect of doing a sysfs scan for PCI
> devices.)
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Since I just pulled in the kernel side earlier today:
Reviewed-by: Daniel
that.
Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.
Thanks,
Daniel, secretary of the board
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
gt; Kristian's concern. I'd suspect that providing reference to the HW
> >> documentation (confirming your assumption) might be beneficial.
> >>
> >
> > Sure, attached is the hang I get if I don't set the restriction in
> > gen8_misc_state.c and try to use the ful
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev
.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Martin Peres martin.pe...@linux.intel.com
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Michał Winiarski michal.winiar...@intel.com
Cc: Daniel Vetter dan...@ffwll.ch
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 15
is needed.
That fixed got cc: stable'ed. If you're still running broken kernels you
don't care enough about anything that I don't think this would matter
either. It was just that it took us a few releases to spot this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
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
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa
On Wed, Mar 11, 2015 at 09:10:01AM -0700, Ian Romanick wrote:
On 03/06/2015 06:30 AM, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 02:38:44PM -0800, Ian Romanick wrote:
On 03/04/2015 10:28 AM, Chad Versace wrote:
That text does not appear in the GL spec. When I read the manpage
alongside
is there no gl entry point in mesa we can abuse and make this happen?
Citing the spec doesn't make the real world issue go away.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa
to for debugging), developers know what might happen. So fully
agreed that hurt feet aren't a concern here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev
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
so that structures can
be validated and IOCTLs rejected if output fields aren't set to zero.
Signed-off-by: Thierry Reding tred...@nvidia.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 2 +-
src/gbm/backends/dri/gbm_dri.c
to catch any
userspace issues we've missed.
-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
-off-by: Kenneth Graunke kenn...@whitecape.org
Yeah, kernel adds the CS stall bit both to the flush right before/after
the batch so this works. The kernel also has a comment so people hopefully
check userspace assumptions when testing this.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Some
is picking the
numbers, since you seem to assume here that ver = 2 means the stuff
actually works. But like Ken said the cmd parser in upstream isn't
really enabled yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
changed, 1 insertion(+), 1 deletion(-)
Cc'd to stable because it's a pretty trivial change and provides a sizable
boost to performance on new hardware.
Both patches are Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Aside: Not using WT on display can lead to corruption (apparently bdw
for
timeout=0) asking to just wait for read-only access. Shouldn't be a lot of
fuzz to pimp the corresponding igt testcase and wire it all up. Or not
that interesting?
Cheers, Daniel
--
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
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
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
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
___
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
) 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
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
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
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
/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
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
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
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
, 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
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
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
://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 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
.
-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
.
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
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
:
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
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
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
, 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
,
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
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
-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
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
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
://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
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
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
;
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
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
, 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
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
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
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
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
;-)
-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
--
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
). 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
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
*/
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
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
... 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 +-
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
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
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
) 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
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
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
201 - 300 of 325 matches
Mail list logo
