[Intel-gfx] [PATCH] intel: merge latest i915_drm.h
On Sat, Dec 12, 2015 at 03:16:59PM +, Emil Velikov wrote: > On 11 December 2015 at 21:55, Jesse Barnes > wrote: > > Pick up context flags, softpin, etc. > > > > Signed-off-by: Jesse Barnes > > --- > > include/drm/i915_drm.h | 57 > > ++ > > 1 file changed, 48 insertions(+), 9 deletions(-) > > > Any objections if we do this (and pretty much every other outdated > header) in a single go, as the header cleanups hit Linus' tree ? > Dave already has then in drm-next :-) Ack. Maybe we should just script this and update before doing a libdrm release in general? Updating from drm-next should never result in broken ABI. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[git pull] drm for 4.4-rc1
On Mon, Dec 14, 2015 at 07:14:09AM +0100, Stefan Lippers-Hollmann wrote: > Hi > > On 2015-12-10, Daniel Vetter wrote: > > On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote: > > > On 2015-11-09, Dave Airlie wrote: > [...] > > > This patch seems to introduce a regression for i915 in Linus' > > > v4.4-rc4-60-g9a0f76f, relative to v4.3 (and 4.3.1), on a sandy-bridge > > > (Intel DH67CL) system with a single HDMI connected monitor (Medion > > > MD20094) > > > attached. Immediately after the modeswitch, the monitor switches off and > > > stays off. Nothing catches my eyes in dmesg or Xorg.0.log, but bisecting > > > the issue points me at: > > > > > > 237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit > > > commit 237ed86c693d8a8e4db476976aeb30df4deac74b > > > Author: Sonika Jindal > > > Date: Tue Sep 15 09:44:20 2015 +0530 > > > > > > drm/i915: Check live status before reading edid > [...] > > This is strange, after connecting a different monitor (Fujitsu-Siemens > Scaleoview D19-1) as a second screen via DVI, both monitors came up fine > and even after removing it (and reverting everything to the status quo > ante), this HDMI connected Medion MD20094 monitor continues to work on > the previously broken sandy-bridge DH67CL mainboard. > Despite this problem being 100% reproducable and bisectable before, > including multiple power cycles and replacing the HDMI cable, I have not > been able to reproduce the issue again. > > > A few things to test: > > - How does that screen fare on a working machine? Would tell us if the > > issue is with the sink or the source. > > It is working fine on a Baytrail-D (ASRock Q1900DC-ITX) and an ivy-bridge > (Gigabyte GA-H77M-D3H r1.1) system - and now on the previously affected > sandy-bridge system (Intel DH67CL) as well. > > > - Please boot up with drm.debug=0xe on a working and broken kernel, grab > > dmesg for both. > > dmesg-v4.4-rc4-113-g0bd0f1e-working.gz is attached, unfortunately I'm no > longer able to reproduce the previous failure (tested with easy of the > bisection steps, identical kernel binaries as before, and v4.4-rc5 as > well), so I can't provide a broken trace. > > > - Extending the timeout magic might be worth a shot like in the below > > patch. Crank up retry if it doesn't help. > [...] > > I can only imagine that it was right beyond the brink of the timeout > before and something had a lasting, but probably subtile, effect on the > timing after temporarily connecting the second screen; it is working now. > > On 2015-12-10, Jani Nikula wrote: > [...] > > The very first thing to do is to ensure you've tried v4.4-rc4, which > > contains > > I tested both plain v4.4-rc4 and v4.4-rc4-60-g9a0f76f > > > commit 0f5a9be15797f78c9a34e432f26c796165b6e49a > > Author: Imre Deak > > Date: Fri Nov 27 18:55:29 2015 +0200 > > > > drm/i915: take a power domain reference while checking the HDMI live > > status > > both containing this patch. > > > Thanks a lot and sorry for your trouble, I'll report back if anything > changes - or if I can reproduce the problem again. Ah no worries, this happens fairly often ;-) Could be the cable had a bad day or something like that. Also someone from intel noticed that the delay isn't quite working like it should (we don't do the full 3x10ms delay), patch for that should go to upstream hopefuly soon. Anyway, thanks for reporting. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [RFC libdrm] intel: Add support for softpin
On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
>
>
> > -Original Message-
> > From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf Of
> > Kristian H?gsberg
> > Sent: Monday, December 14, 2015 1:34 PM
> > To: Song, Ruiling
> > Cc: Winiarski, Michal ; intel-
> > gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben
> > Widawsky
> > ; dri-devel at lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >
> > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling
> > wrote:
> > >> -Original Message-
> > >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
> > Behalf
> > >> Of Micha? Winiarski
> > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > >> To: intel-gfx at lists.freedesktop.org
> > >> Cc: Ben Widawsky ; dri-
> > devel at lists.freedesktop.org;
> > >> mesa-dev at lists.freedesktop.org
> > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > >>
> > >> Softpin allows userspace to take greater control of GPU virtual address
> > >> space and eliminates the need of relocations. It can also be used to
> > >> mirror addresses between GPU and CPU (shared virtual memory).
> > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > >> created. Self-relocs don't make any sense for softpinned objects and can
> > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > >> are marked by asterisk in debug dumps.
> > >>
> > >> Cc: Thomas Daniel
> > >> Cc: Kristian Høgsberg
> > >> Cc: Zou Nanhai
> > >> Cc: Michel Thierry
> > >> Cc: Ben Widawsky
> > >> Cc: Chris Wilson
> > >> Signed-off-by: MichaÅ Winiarski
> > >> ---
> > >> include/drm/i915_drm.h| 4 +-
> > >> intel/intel_bufmgr.c | 9 +++
> > >> intel/intel_bufmgr.h | 1 +
> > >> intel/intel_bufmgr_gem.c | 176
> > >> --
> > >> intel/intel_bufmgr_priv.h | 7 ++
> > >> 5 files changed, 173 insertions(+), 24 deletions(-)
> > >
> > > Will anybody help to push the patch to libdrm? Beignet highly depend on
> > this to implement ocl2.0 svm.
> >
> > Is the kernel patch upstream?
>
> Yes, the kernel patch already merged, see:
> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>
> I find below line of code in libdrm does not match the kernel version. The
> kernel patch defined as:
> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
Please always regenerate the entire headers from the kernel sources using
$ make headers_install
Then copy the headers from the kernel's usr/include/drm to libdrm. Never
patch i915_drm.h manually.
Thanks, Daniel
>
> Hello Michal,
>
> Could you help to rebase the patch against:
> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in i915
> I think we need both 48bit & softpin in libdrm.
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..2b99fc6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
> #define I915_PARAM_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 EXEC_OBJECT_NEEDS_FENCE (1<<0)
> #define EXEC_OBJECT_NEEDS_GTT(1<<1)
> #define EXEC_OBJECT_WRITE(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_PINNED (1<<3)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
> __u64 flags;
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH RFC 7/9] omapfb: move vrfb into omapfb
On 13/12/15 21:13, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Thursday 10 December 2015 16:25:33 Tomi Valkeinen wrote: >> VRFB is only used by omapfb, so we can move it under omapfb's directory. > > Do you see any specific blocker for support of vrfb in omapdss, apart from > finding time (and a reason) to implement it ? You probably mean omapdrm. No, no other reasons. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/1ed475fb/attachment.sig>
[PATCH RFC 8/9] drm/omap: move omapdss & displays under omapdrm
On 13/12/15 21:08, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Thursday 10 December 2015 16:25:34 Tomi Valkeinen wrote: >> Now that omapfb has its own copy of omapdss and display drivers, we can >> move omapdss and display drivers which omapdrm uses to omapdrm's >> directory. >> >> We also need to change the main drm Makefile so that omapdrm directory >> is always entered, because omapdss has a file that always needs to be >> built-in. > > Which file is that ? omapdss-boot-init.c ? I would say "that can't be built > as > a module' instead of 'that always needs to be built-in' as the later implies > (at least for me) that the file always have to be built-in regardless of > whether omapdss support is enabled or not. Yes, ompadss-boot-init.c. I'll change the wording. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/6042a8f1/attachment.sig>
[PATCH libdrm 01/10] tests: Split helpers into library
On Sat, Dec 12, 2015 at 03:26:09PM +, Emil Velikov wrote: > Hi Thierry, all, > > On 9 December 2015 at 17:37, Thierry Reding > wrote: > > From: Thierry Reding > > > > Some of the helpers, such as the pattern drawing helpers or the format > > lookup helpers, have potential to be reused. Move them into a separate > > library to make it easier to share them. > > > > Acked-by: Laurent Pinchart > > Signed-off-by: Thierry Reding > > --- > > CleanSpec.mk| 1 + > > configure.ac| 1 + > > tests/Makefile.am | 2 +- > > tests/modeprint/Makefile.am | 1 + > > tests/modeprint/modeprint.c | 2 +- > > tests/modetest/Android.mk | 1 + > > tests/modetest/Makefile.am | 8 +- > > tests/modetest/buffers.c| 961 > > +--- > > tests/modetest/buffers.h| 12 +- > > tests/modetest/cursor.c | 4 +- > > tests/modetest/modetest.c | 25 +- > > tests/proptest/Makefile.am | 4 +- > > tests/proptest/proptest.c | 3 +- > > tests/util/Android.mk | 39 ++ > > tests/util/Makefile.am | 13 + > > tests/util/Makefile.sources | 6 + > > tests/util/common.h | 33 ++ > > tests/util/format.c | 120 ++ > > tests/util/format.h | 65 +++ > > tests/util/pattern.c| 870 +++ > > tests/util/pattern.h| 39 ++ > > tests/vbltest/Makefile.am | 1 + > > tests/vbltest/vbltest.c | 2 +- > > 23 files changed, 1223 insertions(+), 990 deletions(-) > > create mode 100644 tests/util/Android.mk > > create mode 100644 tests/util/Makefile.am > > create mode 100644 tests/util/Makefile.sources > > create mode 100644 tests/util/common.h > > create mode 100644 tests/util/format.c > > create mode 100644 tests/util/format.h > > create mode 100644 tests/util/pattern.c > > create mode 100644 tests/util/pattern.h > > > As mentioned on IRC, although there might be some minor nitpicks I'd > rather the series in those in and fix them later. Mostly to avoid the > long gap until you get the chance to respin things, but also to spare > Tomi (and others) the need to reinvent them :-) I don't mind doing another round if you point out the nitpicks. I'm hopeful that I'll get around to respinning sooner this time. =) Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/5c903f5c/attachment.sig>
[Intel-gfx] [RFC libdrm] intel: Add support for softpin
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, December 14, 2015 4:28 PM
> To: Song, Ruiling
> Cc: krh at bitplanet.net; Winiarski, Michal ;
> mesa-dev at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; Ben
> Widawsky ; dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>
> On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
> >
> >
> > > -Original Message-
> > > From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf
> Of
> > > Kristian H?gsberg
> > > Sent: Monday, December 14, 2015 1:34 PM
> > > To: Song, Ruiling
> > > Cc: Winiarski, Michal ; intel-
> > > gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben
> Widawsky
> > > ; dri-devel at lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > >
> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling
> > > wrote:
> > > >> -Original Message-
> > > >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
> > > Behalf
> > > >> Of Micha? Winiarski
> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > > >> To: intel-gfx at lists.freedesktop.org
> > > >> Cc: Ben Widawsky ; dri-
> > > devel at lists.freedesktop.org;
> > > >> mesa-dev at lists.freedesktop.org
> > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > >>
> > > >> Softpin allows userspace to take greater control of GPU virtual address
> > > >> space and eliminates the need of relocations. It can also be used to
> > > >> mirror addresses between GPU and CPU (shared virtual memory).
> > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list
> > > >> of
> > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > > >> created. Self-relocs don't make any sense for softpinned objects and
> can
> > > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > > >> are marked by asterisk in debug dumps.
> > > >>
> > > >> Cc: Thomas Daniel
> > > >> Cc: Kristian Høgsberg
> > > >> Cc: Zou Nanhai
> > > >> Cc: Michel Thierry
> > > >> Cc: Ben Widawsky
> > > >> Cc: Chris Wilson
> > > >> Signed-off-by: MichaÅ Winiarski
> > > >> ---
> > > >> include/drm/i915_drm.h| 4 +-
> > > >> intel/intel_bufmgr.c | 9 +++
> > > >> intel/intel_bufmgr.h | 1 +
> > > >> intel/intel_bufmgr_gem.c | 176
> > > >> --
> > > >> intel/intel_bufmgr_priv.h | 7 ++
> > > >> 5 files changed, 173 insertions(+), 24 deletions(-)
> > > >
> > > > Will anybody help to push the patch to libdrm? Beignet highly depend
> on
> > > this to implement ocl2.0 svm.
> > >
> > > Is the kernel patch upstream?
> >
> > Yes, the kernel patch already merged, see:
> > http://cgit.freedesktop.org/drm-
> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> >
> > I find below line of code in libdrm does not match the kernel version. The
> kernel patch defined as:
> > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>
> Please always regenerate the entire headers from the kernel sources using
>
> $ make headers_install
>
> Then copy the headers from the kernel's usr/include/drm to libdrm. Never
> patch i915_drm.h manually.
Thanks for the info. But the problem is libdrm still tracks such kind of header
files.
Should this kind of header file be removed from libdrm? Or any document in
libdrm to make this explicit?
Thanks!
Ruiling
> Thanks, Daniel
>
> >
> > Hello Michal,
> >
> > Could you help to rebase the patch against:
> > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in i915
> > I think we need both 48bit & softpin in libdrm.
> >
> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > index ded43b1..2b99fc6 100644
> > --- a/include/drm/i915_drm.h
> > +++ b/include/drm/i915_drm.h
> > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
> > #define I915_PARAM_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 EXEC_OBJECT_NEEDS_FENCE (1<<0)
> > #define EXEC_OBJECT_NEEDS_GTT (1<<1)
> > #define EXEC_OBJECT_WRITE (1<<2)
> > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> > +#define EXEC_OBJECT_PINNED (1<<3)
> > +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
> > __u64 flags;
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
linux-next: manual merge of the drm-misc tree with Linus' tree
On 12/14/2015 02:12 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
>
> between commit:
>
> 8fbf9d92a7bc ("drm/vmwgfx: Implement the cursor_set2 callback v2")
>
> from Linus' tree and commit:
>
> f80de66eca65 ("drm/vmwgfx: Drop dummy save/restore hooks")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
FWIW, the fix looks correct to me.
/Thomas
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 Jürgen Scholz changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #19 from Jürgen Scholz --- Oh, that probably should have been RESOLVED/FIXED. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/e8aada03/attachment.html>
[Intel-gfx] [RFC libdrm] intel: Add support for softpin
> -Original Message-
> From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf Of
> Kristian H?gsberg
> Sent: Monday, December 14, 2015 1:34 PM
> To: Song, Ruiling
> Cc: Winiarski, Michal ; intel-
> gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben Widawsky
> ; dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>
> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling
> wrote:
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
> Behalf
> >> Of Micha? Winiarski
> >> Sent: Wednesday, September 9, 2015 10:07 PM
> >> To: intel-gfx at lists.freedesktop.org
> >> Cc: Ben Widawsky ; dri-
> devel at lists.freedesktop.org;
> >> mesa-dev at lists.freedesktop.org
> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>
> >> Softpin allows userspace to take greater control of GPU virtual address
> >> space and eliminates the need of relocations. It can also be used to
> >> mirror addresses between GPU and CPU (shared virtual memory).
> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> >> created. Self-relocs don't make any sense for softpinned objects and can
> >> indicate a programming errors, thus are forbidden. Softpinned objects
> >> are marked by asterisk in debug dumps.
> >>
> >> Cc: Thomas Daniel
> >> Cc: Kristian Høgsberg
> >> Cc: Zou Nanhai
> >> Cc: Michel Thierry
> >> Cc: Ben Widawsky
> >> Cc: Chris Wilson
> >> Signed-off-by: MichaÅ Winiarski
> >> ---
> >> include/drm/i915_drm.h| 4 +-
> >> intel/intel_bufmgr.c | 9 +++
> >> intel/intel_bufmgr.h | 1 +
> >> intel/intel_bufmgr_gem.c | 176
> >> --
> >> intel/intel_bufmgr_priv.h | 7 ++
> >> 5 files changed, 173 insertions(+), 24 deletions(-)
> >
> > Will anybody help to push the patch to libdrm? Beignet highly depend on
> this to implement ocl2.0 svm.
>
> Is the kernel patch upstream?
Yes, the kernel patch already merged, see:
http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
I find below line of code in libdrm does not match the kernel version. The
kernel patch defined as:
"#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
Hello Michal,
Could you help to rebase the patch against:
[Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in i915
I think we need both 48bit & softpin in libdrm.
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..2b99fc6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_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 EXEC_OBJECT_NEEDS_FENCE (1<<0)
#define EXEC_OBJECT_NEEDS_GTT (1<<1)
#define EXEC_OBJECT_WRITE (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_PINNED (1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
__u64 flags;
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 Jürgen Scholz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #18 from Jürgen Scholz --- Ilia; the latest build from the padoka PPA is derived from git revision eca8f38. Thus it includes your fix and the game now runs fine for me with all the graphic settings/options that I tested. Thank you very much! I will set the status of the bug to RESOLVED/WORKSFORME, I hope that everybody agrees with this. Thomas; take a look at the command lines I put here. Obviously you will have to adjust them according to your username and possibly to the location of your steam-Data or shell (I use fish) - after that you should be able to get log files and console output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/a1442b3b/attachment.html>
[git pull] drm for 4.4-rc1
Hi On 2015-12-10, Daniel Vetter wrote: > On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote: > > On 2015-11-09, Dave Airlie wrote: [...] > > This patch seems to introduce a regression for i915 in Linus' > > v4.4-rc4-60-g9a0f76f, relative to v4.3 (and 4.3.1), on a sandy-bridge > > (Intel DH67CL) system with a single HDMI connected monitor (Medion MD20094) > > attached. Immediately after the modeswitch, the monitor switches off and > > stays off. Nothing catches my eyes in dmesg or Xorg.0.log, but bisecting > > the issue points me at: > > > > 237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit > > commit 237ed86c693d8a8e4db476976aeb30df4deac74b > > Author: Sonika Jindal > > Date: Tue Sep 15 09:44:20 2015 +0530 > > > > drm/i915: Check live status before reading edid [...] This is strange, after connecting a different monitor (Fujitsu-Siemens Scaleoview D19-1) as a second screen via DVI, both monitors came up fine and even after removing it (and reverting everything to the status quo ante), this HDMI connected Medion MD20094 monitor continues to work on the previously broken sandy-bridge DH67CL mainboard. Despite this problem being 100% reproducable and bisectable before, including multiple power cycles and replacing the HDMI cable, I have not been able to reproduce the issue again. > A few things to test: > - How does that screen fare on a working machine? Would tell us if the > issue is with the sink or the source. It is working fine on a Baytrail-D (ASRock Q1900DC-ITX) and an ivy-bridge (Gigabyte GA-H77M-D3H r1.1) system - and now on the previously affected sandy-bridge system (Intel DH67CL) as well. > - Please boot up with drm.debug=0xe on a working and broken kernel, grab > dmesg for both. dmesg-v4.4-rc4-113-g0bd0f1e-working.gz is attached, unfortunately I'm no longer able to reproduce the previous failure (tested with easy of the bisection steps, identical kernel binaries as before, and v4.4-rc5 as well), so I can't provide a broken trace. > - Extending the timeout magic might be worth a shot like in the below > patch. Crank up retry if it doesn't help. [...] I can only imagine that it was right beyond the brink of the timeout before and something had a lasting, but probably subtile, effect on the timing after temporarily connecting the second screen; it is working now. On 2015-12-10, Jani Nikula wrote: [...] > The very first thing to do is to ensure you've tried v4.4-rc4, which > contains I tested both plain v4.4-rc4 and v4.4-rc4-60-g9a0f76f > commit 0f5a9be15797f78c9a34e432f26c796165b6e49a > Author: Imre Deak > Date: Fri Nov 27 18:55:29 2015 +0200 > > drm/i915: take a power domain reference while checking the HDMI live > status both containing this patch. Thanks a lot and sorry for your trouble, I'll report back if anything changes - or if I can reproduce the problem again. Regards Stefan Lippers-Hollmann -- next part -- A non-text attachment was scrubbed... Name: dmesg-v4.4-rc4-113-g0bd0f1e-working.gz Type: application/gzip Size: 21936 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/89fda1a6/attachment-0001.bin>
[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #12 from Tapani Pälli --- AFAIK this game does not require compute but it does require tessellation. Game renders much better (correct colors, vertex positions) on i965 than the attached video but has bunch of random polygons on top of rendered image which I believe are related to tessellation bugs on i965. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/7252b44d/attachment.html>
[Intel-gfx] [RFC libdrm] intel: Add support for softpin
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf > Of Micha? Winiarski > Sent: Wednesday, September 9, 2015 10:07 PM > To: intel-gfx at lists.freedesktop.org > Cc: Ben Widawsky ; dri-devel at lists.freedesktop.org; > mesa-dev at lists.freedesktop.org > Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin > > Softpin allows userspace to take greater control of GPU virtual address > space and eliminates the need of relocations. It can also be used to > mirror addresses between GPU and CPU (shared virtual memory). > Calls to drm_intel_bo_emit_reloc are still required to build the list of > drm_i915_gem_exec_objects at exec time, but no entries in relocs are > created. Self-relocs don't make any sense for softpinned objects and can > indicate a programming errors, thus are forbidden. Softpinned objects > are marked by asterisk in debug dumps. > > Cc: Thomas Daniel > Cc: Kristian Høgsberg > Cc: Zou Nanhai > Cc: Michel Thierry > Cc: Ben Widawsky > Cc: Chris Wilson > Signed-off-by: MichaŠWiniarski > --- > include/drm/i915_drm.h| 4 +- > intel/intel_bufmgr.c | 9 +++ > intel/intel_bufmgr.h | 1 + > intel/intel_bufmgr_gem.c | 176 > -- > intel/intel_bufmgr_priv.h | 7 ++ > 5 files changed, 173 insertions(+), 24 deletions(-) Will anybody help to push the patch to libdrm? Beignet highly depend on this to implement ocl2.0 svm. Thanks! Ruiling
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #17 from Ilia Mirkin --- FWIW, replaying an apitrace I was given privately with the fix I pushed out works fine on nouveau, so I think the core issues are solved, we're just left with (potential) driver issues. I can't really help you with installing things on your box. Try the latest mesa from the git repo, and make note of any issues you have. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/99274bb5/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #16 from Thomas Kowaliczek --- I know how to install mesa debug. But how can I get logs from the game? Because when I start the game with steam I don't become any log At the moment I have only lastest mesa stable installed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/605b746b/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #15 from Ilia Mirkin --- (In reply to Thomas Kowaliczek from comment #14) > How can i debug the game i want to help to with logs. With a debug build that includes my fix (e.g. checkout from mesa git), what problem do you hit? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/3f926c1f/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #14 from Thomas Kowaliczek --- How can i debug the game i want to help to with logs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151214/7dae4ac9/attachment.html>
