Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
On Mon, 18 Jul 2011 17:00:54 -0700, Chad Versace wrote:
> On 07/18/2011 08:57 AM, Eric Anholt wrote:
> > On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace
> > wrote:
> >> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
> >> b/src/mesa/drivers/dri/intel/intel_fbo.c
> >> index 1669af2..507cc33 100644
> >> --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> >> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> >> @@ -173,6 +173,9 @@ intel_alloc_renderbuffer_storage(struct gl_context *
> >> ctx, struct gl_renderbuffer
> >>
> >> if (irb->Base.Format == MESA_FORMAT_S8) {
> >>/*
> >> + * The stencil buffer is W tiled. However, we request from the
> >> kernel a
> >> + * non-tiled buffer because the GTT is incapable of W fencing.
> >> + *
> >> * The stencil buffer has quirky pitch requirements. From Vol 2a,
> >> * 11.5.6.2.1 3DSTATE_STENCIL_BUFFER, field "Surface Pitch":
> >> *The pitch must be set to 2x the value computed based on
> >> width, as
> >> @@ -180,14 +183,14 @@ intel_alloc_renderbuffer_storage(struct gl_context *
> >> ctx, struct gl_renderbuffer
> >> * To accomplish this, we resort to the nasty hack of doubling the
> >> drm
> >> * region's cpp and halving its height.
> >> *
> >> - * If we neglect to double the pitch, then
> >> drm_intel_gem_bo_map_gtt()
> >> - * maps the memory incorrectly.
> >> + * If we neglect to double the pitch, then render corruption occurs.
> >> */
> >>irb->region = intel_region_alloc(intel->intelScreen,
> >> - I915_TILING_Y,
> >> + I915_TILING_NONE,
> >> cpp * 2,
> >> - width,
> >> - height / 2,
> >> + ALIGN(width, 64),
> >> + /* XXX: Maybe align to 128? */
> >> + ALIGN(height / 2, 64),
> >> GL_TRUE);
> >>if (!irb->region)
> >>return false;
> >
> > This looks like it would fail on a buffer with height = 129.
>
> Oops. It does fail for height = 129. Accordingly, I've changed this hunk to:
>
>irb->region = intel_region_alloc(intel->intelScreen,
> -I915_TILING_Y,
> +I915_TILING_NONE,
> cpp * 2,
> -width,
> -height / 2,
> +ALIGN(width, 64),
> +ALIGN((height + 1)/ 2, 64),
> GL_TRUE);
>
> And changed the same line in xf86-video-intel too.
>
> > Doesn't
> > seem like 128 pitch requirement would be needed -- has it been tested?
>
> The XXX was left in the patch accidentally. 128-alignment has been tested,
> and was
> found unnecessary.
Looks good to me, gets the Reviewed-by: Eric Anholt
pgpZ8dm2JCZZt.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Excessive red or pinkness with Sandy Bridge
Hi, Just wondering if anyone else is experiencing excessive red or pinkness. It's not the laptop screen since an external LCD monitor looks the same. This background (http://www.gnumims.org/) should be a pale yellow #FDFFE2. I guess the contrast is being over driven, is it possible to adjust this? I am using the Debian testing kernel (2.6.38-2-amd64) and 2.15 Intel drivers (xserver-xorg-video-intel/testing uptodate 2:2.15.0-3). I have subscribe to the mailing list. My review of the Samsung RF511: http://www.kromhouts.net/blog/?p=128 Regards Gavin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 915GME support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/14/2011 01:52 PM, Terumichi Sadahiro wrote: > 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? There are a lot of different variations of the "same" chip out there. My guess is that 915GME and 915GM are the same except perhaps clock, memory support, or CPU support. Looking at the chipset comparison (http://ark.intel.com/compare/27715,32279), it seems the primary difference is the 915GM has TV out and the 915GME does not. The 915GME also has "embedded options available," whatever that means. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4lz6EACgkQX1gOwKyEAw+BrQCgiBtT86rArd3Nj0YlNDr+3j/E Z+MAn0K/2mw8x3rzaF/m69IQfAGogHpT =7JZW -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/2011 07:58 AM, Nicolas Kalkhof wrote: > Hi there, > > I've experienced a strange depth buffer issue recently with OpenGL games > (see attached screenshots). It seems that the depth buffer fails on some > pixels. This problem was introduced somewhere between > Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and > mesa are latest git. > Could someone please look into it? That's very odd. Any chance you could bisect to find the bad commit? You should be able to just bisect the drivers/gpu/drm directory. I'm a bit suspicious that this is a kernel issue. There were only 5 commits in drivers/gpu/drm from rc6 to rc7, and none of them should affect any Intel GPUs at all. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4l0OEACgkQX1gOwKyEAw/BWQCfeySgLPcT1bdNxPcTJr/S2aw0 vvkAnjS5OJF18pRwrRKaMyG2zoXFqwqB =AiSG -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
Hi Ian, thx for your reply. ok I give it a try and will report my findings regards nic -Ursprüngliche Nachricht- Von: "Ian Romanick" Gesendet: Jul 19, 2011 8:45:53 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On 07/19/2011 07:58 AM, Nicolas Kalkhof wrote: >> Hi there, >> >> I've experienced a strange depth buffer issue recently with OpenGL games >> (see attached screenshots). It seems that the depth buffer fails on some >> pixels. This problem was introduced somewhere between >> Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and >> mesa are latest git. >> Could someone please look into it? > >That's very odd. Any chance you could bisect to find the bad commit? >You should be able to just bisect the drivers/gpu/drm directory. I'm a >bit suspicious that this is a kernel issue. There were only 5 commits >in drivers/gpu/drm from rc6 to rc7, and none of them should affect any >Intel GPUs at all. >-BEGIN PGP SIGNATURE- >Version: GnuPG v1.4.11 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >iEYEARECAAYFAk4l0OEACgkQX1gOwKyEAw/BWQCfeySgLPcT1bdNxPcTJr/S2aw0 >vvkAnjS5OJF18pRwrRKaMyG2zoXFqwqB >=AiSG >-END PGP SIGNATURE- ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
On 19/07/11 02:58 PM, Nicolas Kalkhof wrote: > I've experienced a strange depth buffer issue recently with OpenGL games (see > attached screenshots). It seems that the depth buffer fails on some pixels. > This problem was introduced somewhere between Kernel-3.0.0-rc6-git6 and > kernel-3.0.0-rc7. Both xf-86-video-intel and mesa are latest git. Could > someone please look into it? I've experienced this issue far earlier than the version stated above (i.e. with 2.39 rc's using mesa and xf86-video-intel from git from that time period). It does not occur constantly in my case, just randomly, and not necessarily from application start (i.e. it sometimes started after it had been running a short period of time). I would have mentioned this earlier if I wasn't having ram issues which make it difficult to have any certainty about problems which occur randomly. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
Hi,absolutely correct! I've experienced this issue the same way you described during the 2.6.39-rc series in random occurance but much less intensive. however it disappeared during the 3.0-rc series. now the depth/alpha issue occurs instantly after starting the OGL app. I'll try to nail down the bad commit.regards,nicVon: Safety0ff Gesendet: Jul 19, 2011 5:12:15 PMAn: intel-gfx@lists.freedesktop.orgBetreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL gamesOn 19/07/11 02:58 PM, Nicolas Kalkhof wrote:I've experienced a strange depth buffer issue recently with OpenGL games (see attached screenshots). It seems that the depth buffer fails on some pixels. This problem was introduced somewhere between Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and mesa are latest git. Could someone please look into it?I've experienced this issue far earlier than the version stated above (i.e. with 2.39 rc's using mesa and xf86-video-intel from git from that time period). It does not occur constantly in my case, just randomly, and not necessarily from application start (i.e. it sometimes started after it had been running a short period of time). I would have mentioned this earlier if I wasn't having ram issues which make it difficult to have any certainty about problems which occur randomly. Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
On 07/18/2011 01:20 AM, Paul Menzel wrote: > Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace: > There are alignment/white space issues above. > >> + unsigned stride = irb->region->pitch;\ >> + unsigned height = 2 * irb->region->height; >> \ >> + bool flip = rb->Name == 0; >> \ > > […] > > > Thanks, > > Paul > Thanks. Fix whitespace in both patches. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
Hi all, ok I've nailed the issue down to 3.0.0-rc7 and 3.0.0-rc7-git1. I suspect that the changes made in drivers/gpu/drm/i915/i915_dma.c are the cause of the problem. http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.0%2Fsnapshots%2Fpatch-3.0-rc7-git1.bz2;z=14 Any Clues? Regards Nic -Ursprüngliche Nachricht- Von: "Nicolas Kalkhof" Gesendet: Jul 19, 2011 9:08:26 PM An: "Ian Romanick" Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games >Hi Ian, > >thx for your reply. ok I give it a try and will report my findings > >regards >nic > >-Ursprüngliche Nachricht- >Von: "Ian Romanick" >Gesendet: Jul 19, 2011 8:45:53 PM >An: "Nicolas Kalkhof" >Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games > >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA1 >> >>On 07/19/2011 07:58 AM, Nicolas Kalkhof wrote: >>> Hi there, >>> >>> I've experienced a strange depth buffer issue recently with OpenGL games >>> (see attached screenshots). It seems that the depth buffer fails on some >>> pixels. This problem was introduced somewhere between >>> Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and >>> mesa are latest git. >>> Could someone please look into it? >> >>That's very odd. Any chance you could bisect to find the bad commit? >>You should be able to just bisect the drivers/gpu/drm directory. I'm a >>bit suspicious that this is a kernel issue. There were only 5 commits >>in drivers/gpu/drm from rc6 to rc7, and none of them should affect any >>Intel GPUs at all. >>-BEGIN PGP SIGNATURE- >>Version: GnuPG v1.4.11 (GNU/Linux) >>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >>iEYEARECAAYFAk4l0OEACgkQX1gOwKyEAw/BWQCfeySgLPcT1bdNxPcTJr/S2aw0 >>vvkAnjS5OJF18pRwrRKaMyG2zoXFqwqB >>=AiSG >>-END PGP SIGNATURE- > > >___ >Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die >Toolbar eingebaut! http://produkte.web.de/go/toolbar >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Netiquette (was: gen6 (SNB) depthbuffer issue with OpenGL games)
Dear Nicolas, unfortunately the Web.de WWW interface has stopped to set the `In-Reply-To` or `References` header fields in the message header and therefore does not adhere to the standard anymore [1]. As a result your messages are not threaded correctly which make keeping an overview harder [2]. Do you have the means to use a mail program like Evolution, Thunderbird, etc. which adhere to the standard? Web.de Freemail supports IMAP so that you could still manage your mail on the server. As a last thing, could you also try to use interleaved style when replying. Doing this is also easier when using mail programs in my experience. Thanks, Paul [1] http://lists.alioth.debian.org/pipermail/pkg-exim4-users/2011-June/001949.html [2] http://en.opensuse.org/openSUSE:Mailing_list_netiquette signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: > +#define SHADER_DEBUG_SOCKET "/tmp/gen_debug" Not sure what this is used for, but does it really need to be in /tmp? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/2011 01:21 PM, Nicolas Kalkhof wrote: > Hi all, > > ok I've nailed the issue down to 3.0.0-rc7 and 3.0.0-rc7-git1. I suspect that > the changes made in > drivers/gpu/drm/i915/i915_dma.c are the cause of the problem. > > http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.0%2Fsnapshots%2Fpatch-3.0-rc7-git1.bz2;z=14 > > Any Clues? Okay, so that's the commit below, which changes some error clean-up paths. That is also odd. What *exact* GPU do you have? Specificially, what's the output of glxinfo | grep "OpenGL renderer" and lspci -vn | grep VGA Does this appear in all games or just certain games? If it's just in certain games, which ones? commit a7b85d2aa63ed09cd5a4a640772b3272f5ac7caa Author: Keith Packard Date: Sun Jul 10 13:12:17 2011 -0700 drm/i915: Clean up i915_driver_load failure path i915_driver_load adds a write-combining MTRR region for the GTT aperture to improve memory speeds through the aperture. If i915_driver_load fails after this, it would not have cleaned up the MTRR. This shouldn't cause any problems, except for consuming an MTRR register. Still, it's best to clean up completely in the failure path, which is easily done by calling mtrr_del if the mtrr was successfully allocated. i915_driver_load calls i915_gem_load which register i915_gem_inactive_shrink. If i915_driver_load fails after calling i915_gem_load, the shrinker will be left registered. When called, it will access freed memory and crash. The fix is to unregister the shrinker in the failure path using code duplicated from i915_driver_unload. i915_driver_load also has some incorrect gotos in the error cleanup paths: * After failing to initialize the GTT (which cannot happen, btw, intel_gtt_get returns a fixed (non-NULL) value), it tries to free the uninitialized WC IO mapping. Fixed this by changing the target from out_iomapfree to out_rmmap Signed-off-by: Keith Packard Tested-by: Lin Ming -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4l8j4ACgkQX1gOwKyEAw+XRACaAzuKEihGpktWtA0UbTwx78NR kBEAoJ7FxkXWEtxC5enkFwnFc19+sPGT =abq+ -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
On 19/07/11 07:18 PM, Nicolas Kalkhof wrote: > Hi, > absolutely correct! I've experienced this issue the same way you > described during the 2.6.39-rc series in random occurance but much > less intensive. however it disappeared during the 3.0-rc series. now > the depth/alpha issue occurs instantly after starting the OGL app. > I'll try to nail down the bad commit. > > regards, > nic Now that I think of it, I believe my ubuntu 32bit installation running 2.6.38 from xorg-edgers was also affected. Regards, -Safety0ff ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: provide more error output when mode sets fail
If a mode set fails we may get a message from drm_crtc_helper if we're lucky,
but it won't tell us anything about *why* we failed to set a mode. So
add a few DRM_ERRORs for the cases that shouldn't happen so we can debug
things more easily.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0f1c799..2434441 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1934,7 +1934,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
/* no fb bound */
if (!crtc->fb) {
- DRM_DEBUG_KMS("No FB bound\n");
+ DRM_ERROR("No FB bound\n");
return 0;
}
@@ -1943,6 +1943,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
case 1:
break;
default:
+ DRM_ERROR("no plane for crtc\n");
return -EINVAL;
}
@@ -1952,6 +1953,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
NULL);
if (ret != 0) {
mutex_unlock(&dev->struct_mutex);
+ DRM_ERROR("pin & fence failed\n");
return ret;
}
@@ -1980,6 +1982,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
if (ret) {
i915_gem_object_unpin(to_intel_framebuffer(crtc->fb)->obj);
mutex_unlock(&dev->struct_mutex);
+ DRM_ERROR("failed to update base address\n");
return ret;
}
--
1.7.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] H.264/AVC encode, Intel® HD Graphics 2000/3000, linux
Is anyone aware of any linux projects (preferably ffmpeg) that can encode H.264/AVC using the iGPU of the sandy bridge Intel® HD Graphics 2000/3000? I see that there is a libva snb-encoder branch in vaapi. Has anyone developed a ffmpeg library that supports this? Sorry if this has been covered, I tried to search the archives, but apparently search isn't working. Is there a better mailing list to ask this question? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Skip GPU wait for scanout pin while wedged
Failing to pin a scanout buffer will most likely lead to a black
screen, so if the GPU is wedged, then just let the pin happen and hope
that things work out OK.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e9d1d5c..d8d623e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3112,9 +3112,15 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
return ret;
if (pipelined != obj->ring) {
- ret = i915_gem_object_wait_rendering(obj);
- if (ret)
- return ret;
+ struct drm_device *dev = obj->base.dev;
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ if (atomic_read(&dev_priv->mm.wedged)) {
+ DRM_ERROR("Skip GPU wait for scanout while wedged\n");
+ } else {
+ ret = i915_gem_object_wait_rendering(obj);
+ if (ret)
+ return ret;
+ }
}
/* The display engine is not coherent with the LLC cache on gen6. As
--
1.7.5.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 915GME support
Hi Matt, Ian. Thanks for your convincing and satisfactory explanation. Unfortunately, I don't have any 915GME board in hand and can't examine that. But I make sense of the situation. Best Regards, Terumichi On Wed, Jul 20, 2011 at 3:40 AM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/14/2011 01:52 PM, Terumichi Sadahiro wrote: > >> 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? > > There are a lot of different variations of the "same" chip out there. > My guess is that 915GME and 915GM are the same except perhaps clock, > memory support, or CPU support. Looking at the chipset comparison > (http://ark.intel.com/compare/27715,32279), it seems the primary > difference is the 915GM has TV out and the 915GME does not. The 915GME > also has "embedded options available," whatever that means. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4lz6EACgkQX1gOwKyEAw+BrQCgiBtT86rArd3Nj0YlNDr+3j/E > Z+MAn0K/2mw8x3rzaF/m69IQfAGogHpT > =7JZW > -END PGP SIGNATURE- > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip GPU wait for scanout pin while wedged
On Tue, 19 Jul 2011 16:26:43 -0700, Keith Packard wrote: > Failing to pin a scanout buffer will most likely lead to a black > screen, so if the GPU is wedged, then just let the pin happen and hope > that things work out OK. This doesn't prevent us returning an error should the wait-rendering abort due to a GPU hang occurring in the middle of the wait. i915_gem_object_pin_to_display_plane is used for more than just the scanout, cursors and overlay are also included, otherwise we could just ignore any errors. So, /* Update the display engine regardless of any GPU hangs */ if (ret == -ERESTARTSYS) return ret; -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: provide more error output when mode sets fail
On Tue, 19 Jul 2011 15:38:56 -0700, Jesse Barnes
wrote:
> If a mode set fails we may get a message from drm_crtc_helper if we're lucky,
> but it won't tell us anything about *why* we failed to set a mode. So
> add a few DRM_ERRORs for the cases that shouldn't happen so we can debug
> things more easily.
Also fix drm not to simply ignore the error codes would also be useful.
But how does logging the error without logging the state help? Presumably
you are targeting the unreproducible cases?
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0f1c799..2434441 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1934,7 +1934,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
>
> /* no fb bound */
> if (!crtc->fb) {
> - DRM_DEBUG_KMS("No FB bound\n");
> + DRM_ERROR("No FB bound\n");
> return 0;
> }
Should this be flagged as en error then?
>
> @@ -1943,6 +1943,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> case 1:
> break;
> default:
> + DRM_ERROR("no plane for crtc\n");
> return -EINVAL;
> }
>
> @@ -1952,6 +1953,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
>NULL);
> if (ret != 0) {
> mutex_unlock(&dev->struct_mutex);
> + DRM_ERROR("pin & fence failed\n");
In this and the following, report the reason/error code for the failure.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip GPU wait for scanout pin while wedged
On Wed, 20 Jul 2011 01:03:17 +0100, Chris Wilson wrote: > This doesn't prevent us returning an error should the wait-rendering abort > due to a GPU hang occurring in the middle of the wait. Yeah, should probably check the return value and ignore the error instead. > i915_gem_object_pin_to_display_plane is used for more than just the > scanout, cursors and overlay are also included, otherwise we could just > ignore any errors. So, Given that the GPU is wedged, I don't see any problem pinning any of these instead of failing. > /* Update the display engine regardless of any GPU hangs */ > if (ret == -ERESTARTSYS) > return ret; Yeah, that seems simpler in all ways. Much nicer. -- keith.pack...@intel.com pgpQceuibWqj8.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: provide more error output when mode sets fail
On Wed, 20 Jul 2011 01:14:47 +0100
Chris Wilson wrote:
> On Tue, 19 Jul 2011 15:38:56 -0700, Jesse Barnes
> wrote:
> > If a mode set fails we may get a message from drm_crtc_helper if
> > we're lucky, but it won't tell us anything about *why* we failed to
> > set a mode. So add a few DRM_ERRORs for the cases that shouldn't
> > happen so we can debug things more easily.
>
> Also fix drm not to simply ignore the error codes would also be
> useful. But how does logging the error without logging the state
> help? Presumably you are targeting the unreproducible cases?
I added these to catch a mode setting failure Keith was seeing
following a GPU hang. The simple debug info was enough to track things
down. But I agree, really the DRM hooks should return ints and give us
more info about what happened, and try to roll back the config.
> > if (!crtc->fb) {
> > - DRM_DEBUG_KMS("No FB bound\n");
> > + DRM_ERROR("No FB bound\n");
> > return 0;
> > }
>
> Should this be flagged as en error then?
Possibly, unless we shut off displays this way??
> > @@ -1952,6 +1953,7 @@ intel_pipe_set_base(struct drm_crtc *crtc,
> > int x, int y, NULL);
> > if (ret != 0) {
> > mutex_unlock(&dev->struct_mutex);
> > + DRM_ERROR("pin & fence failed\n");
>
> In this and the following, report the reason/error code for the
> failure. -Chris
Sure.
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Skip GPU wait for scanout pin while wedged
Failing to pin a scanout buffer will most likely lead to a black
screen, so if the GPU is wedged, then just let the pin happen and hope
that things work out OK.
v2: Just ignore any error from i915_gem_object_wait_rendering, as
suggested by Chris Wilson
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e9d1d5c..e46f273 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3113,7 +3113,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (pipelined != obj->ring) {
ret = i915_gem_object_wait_rendering(obj);
- if (ret)
+ if (ret == -ERESTARTSYS)
return ret;
}
--
1.7.5.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] H.264/AVC encode, Intel? HD Graphics 2000/3000, linux
Hi, Nobody is currently working on ffmpeg support. If you want to start implement, there is an anvenc.c in libva test to begin with. All snb encoding support are now in libva master branch (except B frame and frame rate control support) Those features are developing, we will push them to master later. Snb-encoding branch is outdated. You may also discuss libva on libva maillist. Thanks Zou Nanhai -Original Message- From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org [mailto:intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org] On Behalf Of Brian Brown Sent: 2011年7月20日 6:51 To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] H.264/AVC encode, Intel? HD Graphics 2000/3000, linux Is anyone aware of any linux projects (preferably ffmpeg) that can encode H.264/AVC using the iGPU of the sandy bridge Intel? HD Graphics 2000/3000? I see that there is a libva snb-encoder branch in vaapi. Has anyone developed a ffmpeg library that supports this? Sorry if this has been covered, I tried to search the archives, but apparently search isn't working. Is there a better mailing list to ask this question? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] H.264/AVC encode, Intel(r) HD Graphics 2000/3000, linux
Currently there is a sample application named avcenc in libva to do the h.264 encoding. For the vaapi question, there is a mailing list named li...@lists.freedesktop.org. You can raise your question to it. Hai Lan > -Original Message- > From: intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org > [mailto:intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org] On > Behalf Of Brian Brown > Sent: Wednesday, July 20, 2011 6:51 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] H.264/AVC encode, Intel(r) HD Graphics 2000/3000, linux > > Is anyone aware of any linux projects (preferably ffmpeg) that can encode > H.264/AVC using the iGPU of the sandy bridge Intel(r) HD Graphics 2000/3000? > I see that there is a libva snb-encoder branch in vaapi. Has anyone developed > a ffmpeg library that supports this? Sorry if this has been covered, I tried > to > search the archives, but apparently search isn't working. Is there a better > mailing list to ask this question? > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
