Re: [Intel-gfx] [PATCH v10 00/15] dma-fence: Deadline awareness

[Matt Turner]

On Wed, Mar 8, 2023 at 10:53 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> This series adds a deadline hint to fences, so realtime deadlines
> such as vblank can be communicated to the fence signaller for power/
> frequency management decisions.
>
> This is partially inspired by a trick i915 does, but implemented
> via dma-fence for a couple of reasons:
>
> 1) To continue to be able to use the atomic helpers
> 2) To support cases where display and gpu are different drivers
>
> This iteration adds a dma-fence ioctl to set a deadline (both to
> support igt-tests, and compositors which delay decisions about which
> client buffer to display), and a sw_sync ioctl to read back the
> deadline.  IGT tests utilizing these can be found at:


I read through the series and didn't spot anything. Have a rather weak

Reviewed-by: Matt Turner 

Thanks!

Re: [Intel-gfx] [PATCH v9 15/15] drm/i915: Add deadline based boost support

[Matt Turner]

On Fri, Mar 3, 2023 at 10:08 AM Tvrtko Ursulin
 wrote:
>
>
> On 03/03/2023 14:48, Rob Clark wrote:
> > On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 03/03/2023 03:21, Rodrigo Vivi wrote:
> >>> On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
>  From: Rob Clark 
> 
> >>>
> >>> missing some wording here...
> >>>
>  v2: rebase
> 
>  Signed-off-by: Rob Clark 
>  ---
> drivers/gpu/drm/i915/i915_request.c | 20 
> 1 file changed, 20 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/i915/i915_request.c 
>  b/drivers/gpu/drm/i915/i915_request.c
>  index 7503dcb9043b..44491e7e214c 100644
>  --- a/drivers/gpu/drm/i915/i915_request.c
>  +++ b/drivers/gpu/drm/i915/i915_request.c
>  @@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct 
>  dma_fence *fence)
>    return i915_request_enable_breadcrumb(to_request(fence));
> }
> 
>  +static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t 
>  deadline)
>  +{
>  +struct i915_request *rq = to_request(fence);
>  +
>  +if (i915_request_completed(rq))
>  +return;
>  +
>  +if (i915_request_started(rq))
>  +return;
> >>>
> >>> why do we skip the boost if already started?
> >>> don't we want to boost the freq anyway?
> >>
> >> I'd wager Rob is just copying the current i915 wait boost logic.
> >
> > Yup, and probably incorrectly.. Matt reported fewer boosts/sec
> > compared to your RFC, this could be the bug
>
> Hm, there I have preserved this same !i915_request_started logic.
>
> Presumably it's not just fewer boosts but lower performance. How is he
> setting the deadline? Somehow from clFlush or so?
>
> Regards,
>
> Tvrtko
>
> P.S. Take note that I did not post the latest version of my RFC. The one
> where I fix the fence chain and array misses you pointed out. I did not
> think it would be worthwhile given no universal love for it, but if
> people are testing with it more widely that I was aware perhaps I should.

Yep, that would be great. We're interested in it for ChromeOS. Please
Cc me on the series when you send it.

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone  wrote:
>
> Hi Matt,
>
> On Thu, 27 Feb 2020 at 23:45, Matt Turner  wrote:
> > We're paying 75K USD for the bandwidth to transfer data from the
> > GitLab cloud instance. i.e., for viewing the https site, for
> > cloning/updating git repos, and for downloading CI artifacts/images to
> > the testing machines (AFAIU).
>
> I believe that in January, we had $2082 of network cost (almost
> entirely egress; ingress is basically free) and $1750 of cloud-storage
> cost (almost all of which was download). That's based on 16TB of
> cloud-storage (CI artifacts, container images, file uploads, Git LFS)
> egress and 17.9TB of other egress (the web service itself, repo
> activity). Projecting that out gives us roughly $45k of network
> activity alone, so it looks like this figure is based on a projected
> increase of ~50%.
>
> The actual compute capacity is closer to $1150/month.

Could we have the full GCP bill posted?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

Some clarification I got from Daniel in a private conversation, since
I was confused about what the money was paying for exactly:

We're paying 75K USD for the bandwidth to transfer data from the
GitLab cloud instance. i.e., for viewing the https site, for
cloning/updating git repos, and for downloading CI artifacts/images to
the testing machines (AFAIU).

I was not aware that we were being charged for anything wrt GitLab
hosting yet (and neither was anyone on my team at Intel that I've
asked). This... kind of needs to be communicated.

A consistent concern put forth when we were discussing switching to
GitLab and building CI was... how do we pay for it. It felt like that
concern was always handwaved away. I heard many times that if we
needed more runners that we could just ask Google to spin up a few
more. If we needed testing machines they'd be donated. No one
mentioned that all the while we were paying for bandwidth... Perhaps
people building the CI would make different decisions about its
structure if they knew it was going to wipe out the bank account.

What percentage of the bandwidth is consumed by transferring CI
images, etc? Wouldn't 75K USD would be enough to buy all the testing
machines we need and host them within Google or wherever so we don't
need to pay for huge amounts of bandwidth?

I understand that self-hosting was attractive so that we didn't find
ourselves on the SourceForge-equivalent hosting platform of 2022, but
is that risk real enough to justify spending 75K+ per year? If we were
hosted on gitlab.com or github.com, we wouldn't be paying for
transferring CI images to CI test machines, etc, would we?

So what do we do now? Have we painted ourselves into a corner?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH xf86-video-intel] Fix build on i686

[Matt Turner]

On Wed, Feb 20, 2019 at 11:25 PM Chris Wilson  wrote:
>
> Quoting Matt Turner (2019-02-21 03:23:51)
> > From: Adam Jackson 
> >
> > Presumably this only matters for i686 because amd64 implies sse2, but:
> >
> > BUILDSTDERR: In file included from gen4_vertex.c:34:
> > BUILDSTDERR: gen4_vertex.c: In function 'emit_vertex':
> > BUILDSTDERR: sna_render_inline.h:40:26: error: inlining failed in call to 
> > always_inline 'vertex_emit_2s': target specific option mismatch
> > BUILDSTDERR:  static force_inline void vertex_emit_2s(struct sna *sna, 
> > int16_t x, int16_t y)
> > BUILDSTDERR:   ^~
> > BUILDSTDERR: gen4_vertex.c:308:25: note: called from here
> > BUILDSTDERR:  #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX 
> > assert(!too_large(x, y)); */
> > BUILDSTDERR:  ^~~~
> > BUILDSTDERR: gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX'
> > BUILDSTDERR:   OUT_VERTEX(dstX, dstY);
> > BUILDSTDERR:   ^~
> >
> > The bug here appears to be that emit_vertex() is declared 'sse2' but
> > vertex_emit_2s is merely always_inline. gcc8 decides that since you said
> > always_inline you need to have explicitly cloned it for every
> > permutation of targets. Merely saying inline seems to do the job of
> > cloning vertex_emit_2s as much as necessary.
> >
> > So to reiterate: if you say always-inline, it won't, but if you just say
> > maybe inline, it will. Thanks gcc, that's helpful.
>
> Hasn't this bug occurred in gcc at least twice before?
> -Chris

Looks like some problems that are at least similar have been reported
and fixed in the past. For example:

https://patchwork.kernel.org/patch/6266711/

It appears that Fedora has some other always-inline related patches as well:

https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/master/f/0001-Fix-build-on-F28-and-later.patch
https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/master/f/intel-gcc-pr65873.patch

GCC PR65873 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873) is
titled "Failure to inline always_inline memcpy"...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH xf86-video-intel] Fix build on i686

[Matt Turner]

From: Adam Jackson 

Presumably this only matters for i686 because amd64 implies sse2, but:

BUILDSTDERR: In file included from gen4_vertex.c:34:
BUILDSTDERR: gen4_vertex.c: In function 'emit_vertex':
BUILDSTDERR: sna_render_inline.h:40:26: error: inlining failed in call to 
always_inline 'vertex_emit_2s': target specific option mismatch
BUILDSTDERR:  static force_inline void vertex_emit_2s(struct sna *sna, int16_t 
x, int16_t y)
BUILDSTDERR:   ^~
BUILDSTDERR: gen4_vertex.c:308:25: note: called from here
BUILDSTDERR:  #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX 
assert(!too_large(x, y)); */
BUILDSTDERR:  ^~~~
BUILDSTDERR: gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX'
BUILDSTDERR:   OUT_VERTEX(dstX, dstY);
BUILDSTDERR:   ^~

The bug here appears to be that emit_vertex() is declared 'sse2' but
vertex_emit_2s is merely always_inline. gcc8 decides that since you said
always_inline you need to have explicitly cloned it for every
permutation of targets. Merely saying inline seems to do the job of
cloning vertex_emit_2s as much as necessary.

So to reiterate: if you say always-inline, it won't, but if you just say
maybe inline, it will. Thanks gcc, that's helpful.

Bug: https://bugs.gentoo.org/655206
---
 src/sna/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sna/compiler.h b/src/sna/compiler.h
index 0f3775ec..c4056913 100644
--- a/src/sna/compiler.h
+++ b/src/sna/compiler.h
@@ -32,7 +32,7 @@
 #define likely(expr) (__builtin_expect (!!(expr), 1))
 #define unlikely(expr) (__builtin_expect (!!(expr), 0))
 #define noinline __attribute__((noinline))
-#define force_inline inline __attribute__((always_inline))
+#define force_inline inline
 #define fastcall __attribute__((regparm(3)))
 #define must_check __attribute__((warn_unused_result))
 #define constant __attribute__((const))
-- 
2.19.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Implement 16GB dimm wa for latency level-0

[Matt Turner]

On Thu, Jul 26, 2018 at 7:14 AM, Mahesh Kumar  wrote:
> Bspec: 4381

Do we know that these numbers are stable?

I don't know if this form is common in the kernel, but in Mesa we
specify the name of the page which should always allow readers to find
it.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 20/21] drm/i915: Remove unsafe i915.enable_rc6

[Matt Turner]

On Sun, Nov 19, 2017 at 6:32 AM, Chris Wilson  wrote:
> It has been many years since the last confirmed sighting (and fix) of an
> RC6 related bug (usually a system hang). Remove the parameter to stop
> users from setting dangerous values, as they often set it during triage
> and end up disabling the entire runtime pm instead (the option is not a
> fine scalpel!).

This makes a lot of sense, except for the fact that the next patch
enables RC6 on Ironlake...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Copy user requested buffers into the error state

[Matt Turner]

On Wed, Apr 12, 2017 at 2:43 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> On Wed, Mar 29, 2017 at 04:56:24PM +0100, Chris Wilson wrote:
>> Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
>> use to indicate that it wants the contents of this buffer preserved in
>> the error state (/sys/class/drm/cardN/error) following a GPU hang
>> involving this batch.
>>
>> Use this at your discretion, the contents of the error state. although
>> compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
>> eternity (until the error state is destroyed).
>>
>> Based on an earlier patch by Ben Widawsky <b...@bwidawsk.net>
>> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>> Cc: Ben Widawsky <b...@bwidawsk.net>
>> Cc: Matt Turner <matts...@gmail.com>
>> Acked-by: Ben Widawsky <b...@bwidawsk.net>
>> Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
>
> I believe Matt has userspace ready to make use of this flag and is happy
> with the current ABI. Matt, are we ready to commit ourselves to this
> interface?

Yes, from my end this interface works well.

I'm able to capture the instruction buffer, and recognize it by
matching the "user" buffer's address with that specified by
STATE_BASE_ADDRESS, and then disassemble the various programs
contained within by inspecting the kernel start pointers.

Thanks for handling the kernel side of things!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Copy user requested buffers into the error state

[Matt Turner]

On Wed, Mar 29, 2017 at 8:56 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
> use to indicate that it wants the contents of this buffer preserved in
> the error state (/sys/class/drm/cardN/error) following a GPU hang
> involving this batch.
>
> Use this at your discretion, the contents of the error state. although
> compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
> eternity (until the error state is destroyed).
>
> Based on an earlier patch by Ben Widawsky <b...@bwidawsk.net>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Ben Widawsky <b...@bwidawsk.net>
> Cc: Matt Turner <matts...@gmail.com>
> Acked-by: Ben Widawsky <b...@bwidawsk.net>
> Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---

Thank you, Chris. With this in place (and a few patches from Ben
rebased for libdrm and Mesa) I can disassemble the shader program from
an error state.

In this case, I turned off the end-of-thread bit on the sendc in order
to cause a hang:

render ring --- user = 0x fff75000
pln(8)  g124<1>Fg4<0,1,0>F  g2<8,8,1>F  {
align1 1Q compacted };
pln(8)  g125<1>Fg4.4<0,1,0>Fg2<8,8,1>F  {
align1 1Q compacted };
pln(8)  g126<1>Fg5<0,1,0>F  g2<8,8,1>F  {
align1 1Q compacted };
pln(8)  g127<1>Fg5.4<0,1,0>Fg2<8,8,1>F  {
align1 1Q compacted };
sendc(8)null<1>UW   g124<8,8,1>F
render RT write SIMD8 LastRT Surface = 0
mlen 4 rlen 0 { align1 1Q };
nop ;
pln(16) g120<1>Fg6<0,1,0>F  g2<8,8,1>F  {
align1 1H compacted };
pln(16) g122<1>Fg6.4<0,1,0>Fg2<8,8,1>F  {
align1 1H compacted };
pln(16) g124<1>Fg7<0,1,0>F  g2<8,8,1>F  {
align1 1H compacted };
pln(16) g126<1>Fg7.4<0,1,0>Fg2<8,8,1>F  {
align1 1H compacted };
sendc(16)   null<1>UW   g120<8,8,1>F
render RT write SIMD16 LastRT Surface = 0
mlen 8 rlen 0 { align1 1H };
illegal(1)  { align1 1N };

Presumably we would like to save more than just instruction buffers.
Do we have a good way of discerning what each blob of data in the
error state is?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Sat, 03 Dec 2016, Matt Turner <matts...@gmail.com> wrote:
>> From these instructions, users assume that /sys/class/drm/card0/error
>> contains all the information a developer needs to diagnose and fix a GPU
>> hang.
>>
>> In fact it doesn't, and we have no tools for solving them (other than
>> stabbing in the dark). Most of the time the error state itself isn't
>> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>>
>> Until a time when the error state contains enough information to
>> actually solve a hang, stop telling users to file unsolvable bugs, and
>> instead rely on users who know where and how to file a good bug report
>> to find their own way there.
>>
>> Signed-off-by: Matt Turner <matts...@gmail.com>
>> ---
>> Maybe now's a good time to discuss what *would* be useful to put in the
>> error state for debugging hangs. The currently executing shader program
>> would be a great place to start.
>
> I'm wondering why we're getting this patch now, and my guess is that
> it's because we have been reassigning the related bugs to Mesa more
> actively lately. Is that the case?

No, it's simply because I spent a week going through Bugzilla and
realized how incomplete an unactionable the majority of GPU hang
reports are.

Asking users to report bugs, but not telling them what actually
constitutes a bug report, is a recipe for a lot of wasted developer
time.

I suspect we could improve the usefulness of the reports by directing
users to a webpage that gave a few suggestions (tell us what you were
doing when the hang occurred would be an obvious one) about filing a
bug and then provided a link to Bugzilla. Or even configured Bugzilla
to have a default template that requested various bits of information.

> IIUC the bug reports are useful for us when it's a kernel bug, but less
> useful for you when it's a Mesa bug. And you'd rather have fewer
> incoming bugs that you think are unsolvable with the information at
> hand.
>
> Sounds like a bug workflow issue between drm/i915 and Mesa to be ironed
> out.

Indeed. I'd rather have the information provided in a bug report to
actually solve it. I hope having access to the shader program will
make many more reports useful.

I am also happy to see that there's now a sunset to the GPU hang message.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Copy user requested buffers into the error state

[Matt Turner]

On Sat, Dec 3, 2016 at 7:46 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
> use to indicate that it wants the contents of this buffer preserved in
> the error state (/sys/class/drm/cardN/error) following a GPU hang
> involving this batch.
>
> Use this at your discretion, the contents of the error state. although
> compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
> eternity (until the error state is destroyed).
>
> Based on an earlier patch by Ben Widawsky <b...@bwidawsk.net>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Ben Widawsky <b...@bwidawsk.net>
> Cc: Matt Turner <matts...@gmail.com>
> ---

Thanks Chris.

I would love to give this patch a try, but I can't figure out what it
applies to. It looks like it applies on top of another of your series
-- I looked in your linux-2.6 repo, but didn't spot the appropriate
branch.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

On Fri, Dec 2, 2016 at 5:03 PM, Matt Turner <matts...@gmail.com> wrote:
> From these instructions, users assume that /sys/class/drm/card0/error
> contains all the information a developer needs to diagnose and fix a GPU
> hang.
>
> In fact it doesn't, and we have no tools for solving them (other than
> stabbing in the dark). Most of the time the error state itself isn't
> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>
> Until a time when the error state contains enough information to
> actually solve a hang, stop telling users to file unsolvable bugs, and
> instead rely on users who know where and how to file a good bug report
> to find their own way there.
>
> Signed-off-by: Matt Turner <matts...@gmail.com>
> ---
> Maybe now's a good time to discuss what *would* be useful to put in the
> error state for debugging hangs. The currently executing shader program
> would be a great place to start.

Looks like Ben had a patch:

https://cgit.freedesktop.org/~bwidawsk/drm-intel/commit/?h=extra_error_objs=711da2570cd3302d0cb9f2489a101e4a7c966a6c
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Remove instructions to file a bug report.

[Matt Turner]

From these instructions, users assume that /sys/class/drm/card0/error
contains all the information a developer needs to diagnose and fix a GPU
hang.

In fact it doesn't, and we have no tools for solving them (other than
stabbing in the dark). Most of the time the error state itself isn't
even useful because it just shows a hang on a PIPE_CONTROL or similar.

Until a time when the error state contains enough information to
actually solve a hang, stop telling users to file unsolvable bugs, and
instead rely on users who know where and how to file a good bug report
to find their own way there.

Signed-off-by: Matt Turner <matts...@gmail.com>
---
Maybe now's a good time to discuss what *would* be useful to put in the
error state for debugging hangs. The currently executing shader program
would be a great place to start.

 drivers/gpu/drm/i915/i915_gpu_error.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 334f15d..8ddca7b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1431,7 +1431,6 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
  u32 engine_mask,
  const char *error_msg)
 {
-   static bool warned;
struct drm_i915_error_state *error;
unsigned long flags;
 
@@ -1475,16 +1474,6 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
i915_error_state_free(>ref);
return;
}
-
-   if (!warned) {
-   DRM_INFO("GPU hangs can indicate a bug anywhere in the entire 
gfx stack, including userspace.\n");
-   DRM_INFO("Please file a _new_ bug report on 
bugs.freedesktop.org against DRI -> DRM/Intel\n");
-   DRM_INFO("drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.\n");
-   DRM_INFO("The gpu crash dump is required to analyze gpu hangs, 
so please always attach it.\n");
-   DRM_INFO("GPU crash dump saved to 
/sys/class/drm/card%d/error\n",
-dev_priv->drm.primary->index);
-   warned = true;
-   }
 }
 
 void i915_error_state_get(struct drm_device *dev,
-- 
2.7.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: Use SSE4.1 movntdqa to accelerate reads from WC memory

[Matt Turner]

On Sat, Jul 16, 2016 at 8:44 AM, Chris Wilson  wrote:
> This patch provides the infrastructure for performing a 16-byte aligned
> read from WC memory using non-temporal instructions introduced with sse4.1.
> Using movntdqa we can bypass the CPU caches and read directly from memory
> and ignoring the page attributes set on the CPU PTE i.e. negating the
> impact of an otherwise UC access. Copying using movntqda from WC is almost
> as fast as reading from WB memory, modulo the possibility of both hitting
> the CPU cache or leaving the data in the CPU cache for the next consumer.
> (The CPU cache itself my be flushed for the region of the movntdqa and on
> later access the movntdqa reads from a separate internal buffer for the
> cacheline.) The write back to the memory is however cached.
>
> This will be used in later patches to accelerate accessing WC memory.
>
> v2: Report whether the accelerated copy is successful/possible.
> v3: Function alignment override was only necessary when using the
> function target("sse4.1") - which is not necessary for emitting movntdqa
> from __asm__.
> v4: Improve notes on CPU cache behaviour vs non-temporal stores.
> v5: Fix byte offsets for unrolled moves.
>
> Signed-off-by: Chris Wilson 
> Cc: Akash Goel 
> Cc: Damien Lespiau 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/Makefile  |  3 ++
>  drivers/gpu/drm/i915/i915_drv.c|  2 +
>  drivers/gpu/drm/i915/i915_drv.h|  3 ++
>  drivers/gpu/drm/i915/i915_memcpy.c | 75 
> ++
>  4 files changed, 83 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_memcpy.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 75318ebb8d25..a53853daa998 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -3,12 +3,15 @@
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
>  subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror
> +subdir-ccflags-y += \
> +   $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)
>
>  # Please keep these build lists sorted!
>
>  # core driver code
>  i915-y := i915_drv.o \
>   i915_irq.o \
> + i915_memcpy.o \
>   i915_params.o \
>   i915_pci.o \
>i915_suspend.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c5b7b8e0678a..16612542496a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -848,6 +848,8 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv,
> mutex_init(_priv->wm.wm_mutex);
> mutex_init(_priv->pps_mutex);
>
> +   i915_memcpy_init_early(dev_priv);
> +
> ret = i915_workqueues_init(dev_priv);
> if (ret < 0)
> return ret;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 27d9b2c374b3..3c266e7866ba 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -4070,4 +4070,7 @@ static inline bool __i915_request_irq_complete(struct 
> drm_i915_gem_request *req)
> return false;
>  }
>
> +void i915_memcpy_init_early(struct drm_i915_private *dev_priv);
> +bool i915_memcpy_from_wc(void *dst, const void *src, unsigned long len);
> +
>  #endif
> diff --git a/drivers/gpu/drm/i915/i915_memcpy.c 
> b/drivers/gpu/drm/i915/i915_memcpy.c
> new file mode 100644
> index ..4ed4d3bb2f3e
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_memcpy.c
> @@ -0,0 +1,75 @@
> +#include "i915_drv.h"
> +
> +DEFINE_STATIC_KEY_FALSE(has_movntqa);
> +
> +#ifdef CONFIG_AS_MOVNTDQA
> +static void __movntqda(void *dst, const void *src, unsigned long len)

Many times, you've spelled this movntqda but the instruction mnemonic
is movntdqa (as seen below). I'm not sure if I'm missing something, or
if this typo has somehow slipped in so many times, including in the
commit message.

> +{
> +   len >>= 4;
> +   while (len >= 4) {
> +   __asm__ __volatile__(
> +   "movntdqa (%0), %%xmm0\n"
> +   "movntdqa 16(%0), %%xmm1\n"
> +   "movntdqa 32(%0), %%xmm2\n"
> +   "movntdqa 48(%0), %%xmm3\n"
> +   "movaps %%xmm0, (%1)\n"
> +   "movaps %%xmm1, 16(%1)\n"
> +   "movaps %%xmm2, 32(%1)\n"
> +   "movaps %%xmm3, 48(%1)\n"
> +   : : "r" (src), "r" (dst) : "memory");
> +   src += 64;
> +   dst += 64;
> +   len -= 4;
> +   }
> +   while (len--) {
> +   __asm__ __volatile__(
> +   "movntdqa (%0), %%xmm0\n"
> +   "movaps %%xmm0, (%1)\n"
> +   : : "r" (src), "r" (dst) : "memory");
> +   src += 16;
> +   dst += 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Convert sandybridge_pcode_*() to use intel_wait_for_register()

[Matt Turner]

On Thu, Jun 30, 2016 at 4:30 AM, Chris Wilson  wrote:
> We want to replace the inline wait_for() with an out-of-line hybrid
> busy/sleep wait_for() in the hopes of speeding up the communication wit
> the PCode unit.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Ville Syrjälä 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 43 
> +++--
>  1 file changed, 28 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d7f8ba89d2a5..f84bf253d04a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7623,46 +7623,59 @@ int sandybridge_pcode_read(struct drm_i915_private 
> *dev_priv, u32 mbox, u32 *val
>  {
> WARN_ON(!mutex_is_locked(_priv->rps.hw_lock));
>
> -   if (I915_READ(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY) {
> +   /* GEN6_PCODE_* are outside of the forcewake domain, we can
> +* use te fw I915_READ variants to reduce the amount of work

typo: te -> the
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] how can i check xf86-video-intel version ?

[Matt Turner]

On Sat, Nov 21, 2015 at 5:00 PM, Perez Rodriguez, Humberto I <
humberto.i.perez.rodrig...@intel.com> wrote:

> hi guys,
>
> after compile xf86-video-intel driver, i trying to find how can i check
> its version, by example the latest version so far is : 2.99.917 , so for
> you maybe is easy how to identify it with one terminal command.
>
>
Try:

$ grep -A2 intel_drv /var/log/Xorg.0.log
[17.416] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
[17.418] (II) Module intel: vendor="X.Org Foundation"
[17.418] compiled for 1.17.1, module version = 2.99.917

Also, please send plain-text email to the mailing list (not HTML).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] tools/aubdump: Link with -ldl.

[Matt Turner]

aubdump.c uses dlsym(), so it needs to link with -ldl. Otherwise:

/bin/sh: symbol lookup error: /usr/lib64/intel_aubdump.so: undefined symbol: 
dlsym

Signed-off-by: Matt Turner <matts...@gmail.com>
---
 tools/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 8e454b4..90a8ec1 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -14,7 +14,7 @@ module_LTLIBRARIES = intel_aubdump.la
 moduledir = $(libdir)
 intel_aubdump_la_LDFLAGS = -module -avoid-version -no-undefined
 intel_aubdump_la_SOURCES = aubdump.c intel_aub.h
-intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la
+intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la -ldl
 
 bin_SCRIPTS = intel_aubdump
 CLEANFILES = $(bin_SCRIPTS)
-- 
2.4.9

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

[Matt Turner]

On Wed, Sep 2, 2015 at 10:37 AM, Vivi, Rodrigo  wrote:
> On Wed, 2015-09-02 at 18:16 +0700, David Ho wrote:
>> Dear Rodrigo,
>
> Hi David,
>
> I just paid attention to the subject and notice you are looking for
> driver for GMA 3150. I'm not sure, but I'm afraid this platform doesn't
> have the GPU supported by our open source driver.
>
> Probably the GMA 3150 will be in the same bucket as GMA 3600 series and
> the official statement is at
> https://01.org/linuxgraphics/documentation/faq

The link in the FAQ
(http://download.meego.com/live/MeeGo:/1.2.0:/CedarTrail:/non-oss)
doesn't even work, so that's no good.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

[Matt Turner]

On Wed, Sep 2, 2015 at 9:01 PM, David Ho  wrote:
> Dear Rodrigo,
>
> Thank you for your help.
>
> I'll take a look at the PCI ID.
>
> However,
> when I search GMA 3150 at 01.org, I came across this page:
> https://01.org/linuxgraphics/downloads/2013q1-intel-graphics-stack-release
>
> and also this page at Intel.com
> http://www.intel.com/support/graphics/sb/cs-010512.htm
>
> it seems that the driver of GMA 3150 for older Ubuntu version is available 
> (supported by open source driver).

Wikipedia says GMA 3150 is just a "Pineview" [0]

If so, it's supported by both the i915 kernel and Mesa drivers. But
grep Mesa's include/pci_ids/ to be sure that's what you have.

[0] https://en.wikipedia.org/wiki/Intel_GMA#GMA_3150
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

[Matt Turner]

On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry michel.thie...@intel.com wrote:
 diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
 b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
 index 54081a1..ca90784 100644
 --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
 +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
 @@ -409,11 +409,23 @@ bool
  intel_batchbuffer_emit_reloc64(struct brw_context *brw,

This patch needs to be rebased on commit 09348c12f (committed more
than 3 weeks ago).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915 : Added Programming of the MOCS

[Matt Turner]

On Thu, Jun 4, 2015 at 11:27 AM, Peter Antoine peter.anto...@intel.com wrote:
 This change adds the programming of the MOCS registers to the gen 9+
 platforms. This change set programs the MOCS register values to a set
 of values that are defined to be optimal.

 It creates a fixed register set that is programmed across the different
 engines so that all engines have the same table. This is done as the
 main RCS context only holds the registers for itself and the shared
 L3 values. By trying to keep the registers consistent across the
 different engines it should make the programming for the registers
 consistent.

 Signed-off-by: Peter Antoine peter.anto...@intel.com
 ---
  drivers/gpu/drm/i915/Makefile |   3 +-
  drivers/gpu/drm/i915/i915_reg.h   |   9 ++
  drivers/gpu/drm/i915/intel_lrc.c  |  68 +++
  drivers/gpu/drm/i915/intel_mocs.c | 241 
 ++
  drivers/gpu/drm/i915/intel_mocs.h | 101 
  5 files changed, 421 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/i915/intel_mocs.c
  create mode 100644 drivers/gpu/drm/i915/intel_mocs.h

 diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
 index b7ddf48..cd7b910 100644
 --- a/drivers/gpu/drm/i915/Makefile
 +++ b/drivers/gpu/drm/i915/Makefile
 @@ -36,7 +36,8 @@ i915-y += i915_cmd_parser.o \
   i915_trace_points.o \
   intel_lrc.o \
   intel_ringbuffer.o \
 - intel_uncore.o
 + intel_uncore.o \
 + intel_mocs.o

  # autogenerated null render state
  i915-y += intel_renderstate_gen6.o \
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 7213224..3a435b5 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -7829,4 +7829,13 @@ enum skl_disp_power_wells {
  #define _PALETTE_A (dev_priv-info.display_mmio_offset + 0xa000)
  #define _PALETTE_B (dev_priv-info.display_mmio_offset + 0xa800)

 +/* MOCS (Memory Object Control State) registers */
 +#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
 base */
 +
 +#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
 register*/
 +#define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base 
 register*/
 +#define GEN9_MFX1_MOCS_0   (0xcA00)/* Media 1 MOCS base 
 register*/
 +#define GEN9_VEBOX_MOCS_0  (0xcB00)/* Video MOCS base register*/
 +#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base 
 register*/
 +
  #endif /* _I915_REG_H_ */
 diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
 b/drivers/gpu/drm/i915/intel_lrc.c
 index 9f5485d..c875569 100644
 --- a/drivers/gpu/drm/i915/intel_lrc.c
 +++ b/drivers/gpu/drm/i915/intel_lrc.c
 @@ -135,6 +135,7 @@
  #include drm/drmP.h
  #include drm/i915_drm.h
  #include i915_drv.h
 +#include intel_mocs.h

  #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
  #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE)
 @@ -1370,6 +1371,67 @@ out:
 return ret;
  }

 +/*
 + * i915_gem_program_mocs() - program the MOCS register.
 + *
 + * ring:   The ring that the programming batch will be run in.
 + * ctx:The intel_context to be used.
 + *
 + * This function will emit a batch buffer with the values required for
 + * programming the MOCS register values for all the currenly supported
 + * rings.
 + *
 + * Return: 0 on success, otherwise the error status.
 + */
 +static int i915_gem_program_mocs(struct intel_engine_cs *ring,
 + struct intel_context *ctx)
 +{
 +   int ret = 0;
 +
 +   struct drm_i915_mocs_table t;
 +   struct drm_device *dev = ring-dev;
 +   struct intel_ringbuffer *ringbuf = ctx-engine[ring-id].ringbuf;
 +
 +   if (get_mocs_settings(dev, t)) {
 +   u32 table_size;
 +
 +   /*
 +* OK. For each supported ring:
 +*  table_size * 2 dwords for each control_value
 +*  plus table/2 dwords for l3cc values.
 +*
 +*  Plus 1 for the load command and 1 for the NOOP per ring
 +*  and the l3cc programming.
 +*/
 +   table_size = GEN9_NUM_MOCS_RINGS * ((2 * t.size) + 2) +
 +   t.size + 2;
 +   ret = intel_logical_ring_begin(ringbuf, ctx, table_size);
 +   if (ret) {
 +   DRM_ERROR(intel_logical_ring_begin failed %d\n, 
 ret);
 +   return ret;
 +   }
 +
 +   /* program the control registers */
 +   emit_mocs_control_table(ringbuf, t, GEN9_GFX_MOCS_0);
 +   emit_mocs_control_table(ringbuf, t, GEN9_MFX0_MOCS_0);
 +   emit_mocs_control_table(ringbuf, t, GEN9_MFX1_MOCS_0);
 +   emit_mocs_control_table(ringbuf, t, GEN9_VEBOX_MOCS_0);
 +   emit_mocs_control_table(ringbuf, t, GEN9_BLT_MOCS_0);
 +
 

Re: [Intel-gfx] [PATCH 2/4] drm/cache: Try to be smarter about clflushing on x86

[Matt Turner]

On Sat, Dec 13, 2014 at 7:08 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
 Any GEM driver which has very large objects and a slow CPU is subject to very
 long waits simply for clflushing incoherent objects. Generally, each 
 individual
 object is not a problem, but if you have very large objects, or very many
 objects, the flushing begins to show up in profiles. Because on x86 we know 
 the
 cache size, we can easily determine when an object will use all the cache, and
 forego iterating over each cacheline.

 We need to be careful when using wbinvd. wbinvd() is itself potentially slow
 because it requires synchronizing the flush across all CPUs so they have a
 coherent view of memory. This can result in either stalling work being done on
 other CPUs, or this call itself stalling while waiting for a CPU to accept the
 interrupt. Also, wbinvd() also has the downside of invalidating all 
 cachelines,
 so we don't want to use it unless we're sure we already own most of the
 cachelines.

 The current algorithm is very naive. I think it can be tweaked more, and it
 would be good if someone else gave it some thought. I am pretty confident in
 i915, we can even skip the IPI in the execbuf path with minimal code change 
 (or
 perhaps just some verifying of the existing code). It would be nice to hear 
 what
 other developers who depend on this code think.

 Cc: Intel GFX intel-gfx@lists.freedesktop.org
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/drm_cache.c | 20 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
 index d7797e8..6009c2d 100644
 --- a/drivers/gpu/drm/drm_cache.c
 +++ b/drivers/gpu/drm/drm_cache.c
 @@ -64,6 +64,20 @@ static void drm_cache_flush_clflush(struct page *pages[],
 drm_clflush_page(*pages++);
 mb();
  }
 +
 +static bool
 +drm_cache_should_clflush(unsigned long num_pages)
 +{
 +   const int cache_size = boot_cpu_data.x86_cache_size;
 +
 +   /* For now the algorithm simply checks if the number of pages to be
 +* flushed is greater than the entire system cache. One could make the
 +* function more aware of the actual system (ie. if SMP, how large is
 +* the cache, CPU freq. etc. All those help to determine when to
 +* wbinvd() */
 +   WARN_ON_ONCE(!cache_size);
 +   return !cache_size || num_pages  (cache_size  2);
 +}
  #endif

  void
 @@ -71,7 +85,7 @@ drm_clflush_pages(struct page *pages[], unsigned long 
 num_pages)
  {

  #if defined(CONFIG_X86)
 -   if (cpu_has_clflush) {
 +   if (cpu_has_clflush  drm_cache_should_clflush(num_pages)) {
 drm_cache_flush_clflush(pages, num_pages);
 return;
 }
 @@ -104,7 +118,7 @@ void
  drm_clflush_sg(struct sg_table *st)
  {
  #if defined(CONFIG_X86)
 -   if (cpu_has_clflush) {
 +   if (cpu_has_clflush  drm_cache_should_clflush(st-nents)) {
 struct sg_page_iter sg_iter;

 mb();
 @@ -128,7 +142,7 @@ void
  drm_clflush_virt_range(void *addr, unsigned long length)
  {
  #if defined(CONFIG_X86)
 -   if (cpu_has_clflush) {
 +   if (cpu_has_clflush  drm_cache_should_clflush(length / PAGE_SIZE)) {

If length isn't a multiple of page size, isn't this ignoring the
remainder? Should it be rounding length up to the next multiple of
PAGE_SIZE, like ROUND_UP_TO?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Make sample_c messages go faster on Haswell.

[Matt Turner]

On Wed, Oct 29, 2014 at 2:12 PM, Kenneth Graunke kenn...@whitecape.org wrote:
 Haswell significantly improved the performance of sampler_c messages,
 but the optimization appears to be off by default.  Later platforms
 remove this bit, and apparently always enable the optimization.

 Improves performance in Counter Strike: Global Offensive by 18%
 at default settings on Iris Pro.  No Piglit regressions.

Discussion seems to have ended, but Mesa really needs this.

So, Kernel Team, how are we going to make sure Mesa gets this 18%
performance improvement?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Graphics driver Init code

[Matt Turner]

On Tue, Aug 19, 2014 at 11:29 AM, Dushyant Behl
myselfdushyantb...@gmail.com wrote:
 Ping.


 On Thu, Aug 14, 2014 at 2:55 AM, Dushyant Behl
 myselfdushyantb...@gmail.com wrote:

 Hi Everyone,

 I am an Operating system developer and I'm working on a project for
 which I wanted to understand the working of Intel Graphics Driver.
 Being somewhat new in this field, Can I ask anyone to point me where
 should I start digging in the code? I mean where the graphic driver
 initializes contact with the GPU.

 I'm extremely sorry if I broke any mailing list etiquette. Please forgive
 me.

 Thanks in Advance,
 Dushyant Behl


 I would be really thankful if someone can help me.

All of the code exists in

   drivers/gpu/drm/i915

i915_drv.c contains i915_init, which is the first thing that gets
called when the module is loaded.

From there, there's another 67k lines of code that should keep you busy. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: enable HiZ Raw Stall Optimization on HSW

[Matt Turner]

On Wed, Jan 29, 2014 at 9:56 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Jan 28, 2014 at 6:29 AM, Chia-I Wu olva...@gmail.com wrote:
 From: Chia-I Wu o...@lunarg.com

 The optimization is available on Ivy Bridge and later, and is disabled by
 default.  Enabling it helps certain workloads such as GLBenchmark TRex test.

 No piglit regression.

 v2
  - no need to save the register before suspend as init_clock_gating can
correctly program it after resume
  - split IVB change to another commit

 Signed-off-by: Chia-I Wu o...@lunarg.com

 What about byt?
 -Daniel

In the previous thread, Ville pointed out that the documentation
doesn't say anything about BYT for this bit, so it's unknown whether
it's supported, and Chia-I said

 Though I will leave BDW/VLV out as I do not have the hardware.

I do have BYT, so I'll check it out, but this patch can go in without
it that information, since Chia-I took Ville's advice and split the
patches into per-generation hunks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH intel-gpu-tools] configure: Don't bail if libdrm_nouveau isn't available.

[Matt Turner]

On Fri, Oct 11, 2013 at 12:40 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Oct 11, 2013 at 5:56 AM, Matt Turner matts...@gmail.com wrote:
 We were seriously *requiring* libdrm_nouveau unless explicitly disabled?

 I've had a bit of hilarious fail with optional testcases that
 automatically get disabled when depencies aren't around. Hence why
 they're all required by default with the optional switch to disable
 them.

You've had this problem in general, or with nouveau?

I mean, this is kind of how autotools is supposed to work. If you
explicitly want to ensure something is built you add --enable-thing.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH intel-gpu-tools] configure: Don't bail if libdrm_nouveau isn't available.

[Matt Turner]

On Fri, Oct 11, 2013 at 2:24 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Oct 11, 2013 at 12:51:34PM -0700, Matt Turner wrote:
 On Fri, Oct 11, 2013 at 12:40 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Fri, Oct 11, 2013 at 5:56 AM, Matt Turner matts...@gmail.com wrote:
  We were seriously *requiring* libdrm_nouveau unless explicitly disabled?
 
  I've had a bit of hilarious fail with optional testcases that
  automatically get disabled when depencies aren't around. Hence why
  they're all required by default with the optional switch to disable
  them.

 You've had this problem in general, or with nouveau?

 In general.

So I think what I'm saying is that the nouveau support in
intel-gpu-tools isn't the project's primary purpose, so we should
allow it to build without nouveau support if you don't have nouveau
installed. If you don't have nouveau installed, you're not making a
mistake by not building intel-gpu-tools without support. And if you
have nouveau installed, you still get nouveau support.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH intel-gpu-tools] Depend on libdrm_intel = 2.4.47.

[Matt Turner]

---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 9777bcc..36765f0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -70,7 +70,7 @@ if test x$GCC = xyes; then
 fi
 AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 
-PKG_CHECK_MODULES(DRM, [libdrm_intel = 2.4.40 libdrm])
+PKG_CHECK_MODULES(DRM, [libdrm_intel = 2.4.47 libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess = 0.10])
 PKG_CHECK_MODULES(OVERLAY_XVLIB, [xv x11 xext], enable_overlay_xvlib=yes, 
enable_overlay_xvlib=no)
 PKG_CHECK_MODULES(OVERLAY_XLIB, [cairo-xlib], enable_overlay_xlib=yes, 
enable_overlay_xlib=no)
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH intel-gpu-tools] configure: Don't bail if libdrm_nouveau isn't available.

[Matt Turner]

We were seriously *requiring* libdrm_nouveau unless explicitly disabled?
---
 configure.ac | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index f65942f..43740f9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,8 +92,11 @@ AM_CONDITIONAL(BUILD_ASSEMBLER, [test x$enable_assembler = 
xyes])
 # -
 # for dma-buf tests
 AC_ARG_ENABLE(nouveau, AS_HELP_STRING([--disable-nouveau],
- [Enable use of nouveau API for prime tests (default: enabled)]),
- [NOUVEAU=$enableval], [NOUVEAU=yes])
+ [Enable use of nouveau API for prime tests (default: auto)]),
+ [NOUVEAU=$enableval], [NOUVEAU=auto])
+if test x$NOUVEAU = xauto; then
+   PKG_CHECK_EXISTS([libdrm_nouveau = 2.4.33], [NOUVEAU=yes], 
[NOUVEAU=no])
+fi
 if test x$NOUVEAU = xyes; then
PKG_CHECK_MODULES(DRM_NOUVEAU, [libdrm_nouveau = 2.4.33])
AC_DEFINE(HAVE_NOUVEAU, 1, [Have nouveau support])
-- 
1.8.3.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH intel-gpu-tools] assembler: Add support for the SENDC instruction.

[Matt Turner]

---
 assembler/gram.y | 20 
 assembler/lex.l  |  1 +
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/assembler/gram.y b/assembler/gram.y
index 50d71d1..09f21f1 100644
--- a/assembler/gram.y
+++ b/assembler/gram.y
@@ -440,7 +440,7 @@ static void resolve_subnr(struct brw_reg *reg)
 %token integer MUL MAC MACH LINE SAD2 SADA2 DP4 DPH DP3 DP2
 %token integer AVG ADD SEL AND OR XOR SHR SHL ASR CMP CMPN PLN
 %token integer ADDC BFI1 BFREV CBIT F16TO32 F32TO16 FBH FBL
-%token integer SEND NOP JMPI IF IFF WHILE ELSE BREAK CONT HALT MSAVE
+%token integer SEND SENDC NOP JMPI IF IFF WHILE ELSE BREAK CONT HALT MSAVE
 %token integer PUSH MREST POP WAIT DO ENDIF ILLEGAL
 %token integer MATH_INST
 %token integer MAD LRP BFE BFI2 SUBB
@@ -494,6 +494,7 @@ static void resolve_subnr(struct brw_reg *reg)
 %type integer instoption
 %type integer unaryop binaryop binaryaccop breakop
 %type integer trinaryop
+%type integer sendop
 %type condition conditionalmodifier 
 %type predicate predicate
 %type options instoptions instoption_list
@@ -1099,7 +1100,10 @@ trinaryinstruction:
 }
 ;
 
-sendinstruction: predicate SEND execsize exp post_dst payload msgtarget
+sendop:SEND | SENDC
+;
+
+sendinstruction: predicate sendop execsize exp post_dst payload msgtarget
MSGLEN exp RETURNLEN exp instoptions
{
  /* Send instructions are messy.  The first argument is the
@@ -1163,7 +1167,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
payload msgtarget
   GEN($$)-bits3.generic.end_of_thread = 
$12.end_of_thread;
  }
}
-   | predicate SEND execsize dst sendleadreg payload 
directsrcoperand instoptions
+   | predicate sendop execsize dst sendleadreg payload 
directsrcoperand instoptions
{
  memset($$, 0, sizeof($$));
  set_instruction_opcode($$, $2);
@@ -1181,7 +1185,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
payload msgtarget
YYERROR;
 
  }
-   | predicate SEND execsize dst sendleadreg payload imm32reg 
instoptions
+   | predicate sendop execsize dst sendleadreg payload imm32reg 
instoptions
 {
  if ($7.reg.type != BRW_REGISTER_TYPE_UD 
  $7.reg.type != BRW_REGISTER_TYPE_D 
@@ -1202,7 +1206,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
payload msgtarget
  if (set_instruction_src1($$, $7, @7) != 0)
YYERROR;
 }
-   | predicate SEND execsize dst sendleadreg sndopr imm32reg 
instoptions
+   | predicate sendop execsize dst sendleadreg sndopr imm32reg 
instoptions
{
  struct src_operand src0;
 
@@ -1243,7 +1247,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
payload msgtarget
 
   GEN($$)-bits3.generic_gen5.end_of_thread = !!($6  
EX_DESC_EOT_MASK);
}
-   | predicate SEND execsize dst sendleadreg sndopr 
directsrcoperand instoptions
+   | predicate sendop execsize dst sendleadreg sndopr 
directsrcoperand instoptions
{
  struct src_operand src0;
 
@@ -1284,7 +1288,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
payload msgtarget
   set_instruction_src1($$, $7, @7);
   GEN($$)-bits3.generic_gen5.end_of_thread = !!($6  
EX_DESC_EOT_MASK);
}
-   | predicate SEND execsize dst sendleadreg payload sndopr 
imm32reg instoptions
+   | predicate sendop execsize dst sendleadreg payload sndopr 
imm32reg instoptions
{
  if ($8.reg.type != BRW_REGISTER_TYPE_UD 
  $8.reg.type != BRW_REGISTER_TYPE_D 
@@ -1310,7 +1314,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
payload msgtarget
  GEN($$)-bits3.generic_gen5.end_of_thread = !!($7  
EX_DESC_EOT_MASK);
  }
}
-   | predicate SEND execsize dst sendleadreg payload exp 
directsrcoperand instoptions
+   | predicate sendop execsize dst sendleadreg payload exp 
directsrcoperand instoptions
{
  memset($$, 0, sizeof($$));
  set_instruction_opcode($$, $2);
diff --git a/assembler/lex.l b/assembler/lex.l
index 769d98b..4f1f961 100644
--- a/assembler/lex.l
+++ b/assembler/lex.l
@@ -129,6 +129,7 @@ yylval.integer = BRW_CHANNEL_W;
 subb { yylval.integer = BRW_OPCODE_SUBB; return SUBB; }
 
 send { yylval.integer = BRW_OPCODE_SEND; return SEND; }
+sendc { yylval.integer = BRW_OPCODE_SENDC; return SENDC; }
 nop { yylval.integer = BRW_OPCODE_NOP; return NOP; }
 jmpi { yylval.integer = BRW_OPCODE_JMPI; return JMPI; }
 if { yylval.integer = BRW_OPCODE_IF; return IF; }
-- 
1.8.1.5

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Enable FBC at Ivybridge.

[Matt Turner]

On Tue, Apr 23, 2013 at 10:52 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
 This patch introduce Frame Buffer Compression (FBC) support for IVB,
 without enabling it by default.

The summary is kind of confusing, since FBC isn't being enabled by default.

Maybe change it to drm/i915: Add support for FBC on Ivybridge.?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 回复： [ASK] How can I set the X to select the DRI driveri965

[Matt Turner]

On Wed, Apr 17, 2013 at 12:43 AM, 熊 546496...@qq.com wrote:
 Yah, you mean the DRI driver i965 does not support my device 945GM ?
 but according to
 https://01.org/linuxgraphics/downloads/2012/2012q4-intel-graphics-stack-release,
 it should support my device.

No, that means that they also test the i915 driver (which supports your i945).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH intel-gpu-tools 1/2] Put -I m4 in ACLOCAL_AMFLAGS so ./autogen.sh just works

[Matt Turner]

---
 Makefile.am |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 0dd615b..20bca79 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,7 +19,7 @@
 #  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
-ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
+ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
 
 SUBDIRS = lib man tools scripts benchmarks demos
 
-- 
1.7.8.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH intel-gpu-tools 2/2] quick_dump: Makefile.am best practices and fix distcheck

[Matt Turner]

A few changes
  - Put CPPFLAGS in AM_CPPFLAGS instead of a per-target CFLAGS var;
  - Use _LIBS/_CFLAGS from pkg-config instead of hard-coded values;
  - List non-generated scripts in dist_bin_SCRIPTS;
  - Add chipset.py to the run that implicitly generates it, which fixes
distcheck.
---
 tools/quick_dump/Makefile.am |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/quick_dump/Makefile.am b/tools/quick_dump/Makefile.am
index e89a115..42ab140 100644
--- a/tools/quick_dump/Makefile.am
+++ b/tools/quick_dump/Makefile.am
@@ -1,17 +1,19 @@
+AM_CPPFLAGS = -I$(top_srcdir)/lib $(PYTHON_CPPFLAGS) $(DRM_CFLAGS)
+
 BUILT_SOURCES = chipset_wrap_python.c
 
-bin_SCRIPTS = quick_dump.py chipset.py reg_access.py
+dist_bin_SCRIPTS = quick_dump.py reg_access.py
+bin_SCRIPTS = chipset.py
 
 lib_LTLIBRARIES = I915ChipsetPython.la
-I915ChipsetPython_la_CFLAGS = -I$(top_srcdir)/lib $(PYTHON_CPPFLAGS) $(CFLAGS) 
-I/usr/include/libdrm/
-I915ChipsetPython_la_LDFLAGS = -module -avoid-version $(PYTHON_LDFLAGS) 
-lpciaccess
+I915ChipsetPython_la_LDFLAGS = -module -avoid-version $(PYTHON_LDFLAGS) 
$(PCIACCESS_LIBS)
 I915ChipsetPython_la_SOURCES = chipset_wrap_python.c intel_chipset.c \
   $(top_srcdir)/lib/intel_drm.c  \
   $(top_srcdir)/lib/intel_pci.c  \
   $(top_srcdir)/lib/intel_reg_map.c  \
   $(top_srcdir)/lib/intel_mmio.c
 
-chipset_wrap_python.c: chipset.i
+chipset_wrap_python.c chipset.py: chipset.i
$(SWIG) $(AX_SWIG_PYTHON_OPT) -I/usr/include -I$(top_srcdir)/lib -o $@ 
$
 
 all-local: I915ChipsetPython.la
-- 
1.7.8.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/10] quick_dump: SWIG chipset interface

[Matt Turner]

On Sat, Feb 2, 2013 at 4:08 PM, Ben Widawsky b...@bwidawsk.net wrote:
 This isn't strictly necessary it would have been easy enough to simply
 convert intel_chipset.h but this should be nice prep work for directly
 doing MMIO. It also serves as a nice review point.

 It's demonstrated with an autodetect function in the script. That
 autodetect has a hardcoded path that shouldn't be there, but it will go
 away in the next patch when we can properly link in libpciaccess.

 Thanks to Matt for helping whip the automake stuff into shape.

 Cc: Matt Turner matts...@gmail.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---

Patches 7  8 are Reviewed-by: Matt Turner matts...@gmail.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Workaround to bump rc6 voltage to 450

[Matt Turner]

On Wed, Sep 26, 2012 at 10:34 AM, Ben Widawsky b...@bwidawsk.net wrote:
 BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or
 buggy BIOSen may not be doing this, so we correct it for them. Ideally
 customers should update the BIOS as only it would know the optimal
 values for the platform, so we leave that fact as a DRM_ERROR for the
 user to see.

 Unfortunately this isn't fixing any of the issues it was targeted to
 fix, but it is documented that we must do it.

 CC: Jesse Barnes jbar...@virtuousgeek.org
 CC: Matt Turner matts...@gmail.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_reg.h |  4 
  drivers/gpu/drm/i915/intel_pm.c | 18 --
  2 files changed, 20 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index a828e90..13aafa5 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -4213,6 +4213,10 @@
  #define   GEN6_READ_OC_PARAMS  0xc
  #define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
  #define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
 +#define  GEN6_PCODE_WRITE_RC6VIDS  0x4
 +#define  GEN6_PCODE_READ_RC6VIDS   0x5
 +#define   GEN6_ENCODE_RC6_VID(mv)  (((mv) / 5) - 245)  0 ?: 0
 +#define   GEN6_DECODE_RC6_VID(vids)(((vids) * 5)  0 ? ((vids) * 
 5) + 245 : 0)
  #define GEN6_PCODE_DATA0x138128
  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT   8

 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 6488cd0..9a6edf0 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2404,10 +2404,10 @@ static void gen6_enable_rps(struct drm_device *dev)
 struct intel_ring_buffer *ring;
 u32 rp_state_cap;
 u32 gt_perf_status;
 -   u32 pcu_mbox, rc6_mask = 0;
 +   u32 rc6vids, pcu_mbox, rc6_mask = 0;
 u32 gtfifodbg;
 int rc6_mode;
 -   int i;
 +   int i, ret;

 WARN_ON(!mutex_is_locked(dev-struct_mutex));

 @@ -2526,6 +2526,20 @@ static void gen6_enable_rps(struct drm_device *dev)
 /* enable all PM interrupts */
 I915_WRITE(GEN6_PMINTRMSK, 0);

 +   rc6vids = 0;
 +   ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, 
 rc6vids);
 +   if (IS_GEN6(dev)  ret) {
 +   DRM_DEBUG_DRIVER(Couldn't check for BIOS workaround\n);
 +   } else if (IS_GEN6(dev)  (GEN6_DECODE_RC6_VID(rc6vids  0xff)  
 450)) {
 +   DRM_ERROR(You should update your BIOS. Correcting minimum 
 rc6 voltage (%dmV-%dmV)\n,
 + GEN6_DECODE_RC6_VID(rc6vids  0xff), 450);
 +   rc6vids = 0x00;
 +   rc6vids |= GEN6_ENCODE_RC6_VID(450);
 +   ret = sandybridge_pcode_write(dev_priv, 
 GEN6_PCODE_WRITE_RC6VIDS, rc6vids);
 +   if (ret)
 +   DRM_ERROR(Couldn't fix incorrect rc6 voltage\n);
 +   }
 +
 gen6_gt_force_wake_put(dev_priv);
  }

 --
 1.7.12.1


Tested-by: Matt Turner matts...@gmail.com

(feel free to apply that to the whole series)

Too bad it's not this bug that affects my system. :(
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] MESA compilation problem

[Matt Turner]

On Sat, Aug 4, 2012 at 9:19 AM, Виктор n_vi...@mail.ru wrote:
 gmake[2]: g++: Command not found

Install a C++ compiler.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] gstreamer-vaapi does not work with g45

[Matt Turner]

On Tue, May 29, 2012 at 6:54 AM, Niccolò Belli
darkba...@linuxsystems.it wrote:
 Il 29/05/2012 11:36, Oliver Seitz ha scritto:

 But isn't this a decision to be made by the mainline maintainers?


 Obviously, but why shouldn't they reject a widely requested feature when the
 code is mature enough?
 By the way, since there are no ebuilds with the latest code available (I
 still can't believe it) I made my own media-video/mplayer-1.0_rc4_p20120116
 ebuild with the vaapi use flag. I will post it as soon as I finish to set up
 git on my server.

 Niccolò

fyi, I just filed a request for gstreamer-vaapi yesterday:
https://bugs.gentoo.org/show_bug.cgi?id=418077

The gstreamer maintainers are behind, but I hope they'll get to it soon.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: use DDC_ADDR instead of hard-coding it

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 drivers/gpu/drm/i915/intel_modes.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index 3b26a3b..ab534be 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -27,6 +27,7 @@
 #include linux/i2c.h
 #include linux/fb.h
 #include drmP.h
+#include drm_edid.h
 #include intel_drv.h
 #include i915_drv.h
 
@@ -41,13 +42,13 @@ bool intel_ddc_probe(struct intel_encoder *intel_encoder, 
int ddc_bus)
u8 buf[2];
struct i2c_msg msgs[] = {
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = I2C_M_RD,
.len = 1,
.buf = buf,
-- 
1.7.3.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 915GME support

[Matt Turner]

On Thu, Jul 14, 2011 at 4:52 PM, Terumichi Sadahiro rumi...@gmail.com wrote:
 Hi all,

 I can't find any description about 915GME (not 915GM) in
 intellinuxgraphics.org at all.
 Does this device have so little demand for, or is there any problem?

 Best Regards,
 Terumichi

It should work. Have you tried it and found otherwise?

Matt
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3d performance very low

[Matt Turner]

On Thu, Jul 29, 2010 at 11:15 AM, Hanno Böck ha...@hboeck.de wrote:
 Am Donnerstag 29 Juli 2010 schrieb Tino Keitel:
 When I tried Mesa 7.8 from Debian experimental I got stuttering 3D
 output, at least in neverball and glxgears. I tried libdrm2 2.4.18,
 2.4.21, kernel 2.6.34, 2.6.35-rc5, and the Intel driver 2.11 and 2.12,
 without a change to the stuttering. The Xserver is 1.7.7. the FPS
 output in glxgears was even higher than with Mesa 7.7, but it looked
 ugly because of the stuttering. Do you have a chance to downgrade to
 Mesa 7.7?

 Tried 7.7.1, no change in performance.

 --
 Hanno Böck              Blog:           http://www.hboeck.de/
 GPG: 3DBD3B20           Jabber/Mail:    ha...@hboeck.de

 http://schokokeks.org - professional webhosting

You're saying it's slow, but in relation to what? Were previous
versions faster, or is the comparison being made between hardware?

Matt
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx