Re: [Intel-gfx] IVB Forcewake IRQ patches merged to drm-intel-fixes

[Daniel Vetter]

On Thu, Jan 19, 2012 at 09:22:08PM -0800, Keith Packard wrote:
> 
> I've merged all of the patches for the forcewake work-around for IVB irq
> issues to the drm-intel-fixes branch, along with a handful of other
> pending fixes. I plan to send this upstream after it has seen suitable
> testing, so please let me know if you're able to test this on IVB
> hardware.

The last patch to revert the busy-loop w/a from Eric is missing your sob
line. You can also add Acked-by: Daniel Vetter  to
it if you want.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Make XAA support optional

[Glen Gray]

On 19 Jan 2012, at 17:25, Daniel Vetter wrote:

> On Thu, Jan 19, 2012 at 05:22:56PM +, Glen Gray wrote:
>> 
>> On 18 Jan 2012, at 12:41, Daniel Vetter wrote:
>> 
>>> On Wed, Jan 18, 2012 at 12:27:49PM +, Chris Wilson wrote:
 On Wed, 18 Jan 2012 13:04:43 +0100, Daniel Vetter  wrote:
> On Wed, Jan 18, 2012 at 10:37:24AM +, Chris Wilson wrote:
>> On Wed, 18 Jan 2012 14:45:51 +1100, Daniel Stone  
>> wrote:
>>> Does what it says on the box.
>> 
>> Danvet can you please test this on your elderly i810 box and make sure
>> we don't accidentally open the can of worms. Any sign of regressions?
> 
> Why don't we just rip it out entirely? If a bored soul ever ports this
> driver to kms we likely just need to reimplement proper accel with sna, so
> I don't think there's much value.
 
 If we did rip it out, what happens? The X server uses the vesa driver,
 which is equivalent to i810 for modesetting, no 3d support, no overlays,
 and no accelerated blits (which is dying anyway). Am I right in thinking
 that after removal of XAA, the legacy i810 offers no more functionality
 or performance than is available through VESA?
>>> 
>>> Afaict we're still have left
>>> - dri1 for glxgears
>>> - Xv for video, even XvMC might still work
>>> - modesettting, the driver only uses vesa to grab the edid, but does all
>>> the modesetting with direct vga register banging. Yep, I'm running my
>>> i815 on a 1920x1080 screen, pretty sure that mode isn't in the vesa
>>> bios.
>> 
>> Being responsible for thousands of boxes with i855 chips, deployed
>> across the world, I'm nervous about these discussions. We typically run
>> at resolutions of 1360x768 and use XVideo for IPTV playback. Admittedly
>> these devices will be EOL at some point, but the longer I can keep them
>> updated software wise the happier I'll be.
>> 
>> On my todo list is to test the latest and greatest releases with sna
>> enabled on those devices.  -- 
> 
> These discussions are about the i81x, _not_ any later gen2 device. Afaics
> I'm about the only serious user of that stuff left, at least concering the
> use of the latest and greatest upstream code ...

Understood, I just parsed it to read i8xx. 
-- 
Glen Gray






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

[Intel-gfx] [PATCH] drm/i915: clarify gen2 pageflip cmd

[Daniel Vetter]

I've reviewed gen2 pageflip code do hunt down multple prepare pageflip
issues. The only thing I've found is a slight but functionally
meaningless confusion about the length of the mi cmd.

Fix it up and add a comment about what this dword should be (according
to docs at least).

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5ba19df..417661b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7291,7 +7291,7 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
 MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
OUT_RING(fb->pitches[0]);
OUT_RING(obj->gtt_offset + offset);
-   OUT_RING(MI_NOOP);
+   OUT_RING(0); /* aux display base address, unused */
ADVANCE_LP_RING();
 out:
return ret;
-- 
1.7.8.3

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

[Intel-gfx] Updated -next

[Daniel Vetter]

Hi all,

Not much in the first -next update under the new process, I'd like to
tests the qa process first. Highligths:
- first part of i9xx_crtc_mode_set refactor from Jesse
- quite a few ajax-is-paranoid patches
- HAS_LLC param from Eugeni
- kill i915_mem.c

For easier testing there's also an updated drm-intel-testing branch with
the latest -fixes merged in (i.e. the missed irq patches). Testing
feedback highly welcome.

Hi Yi,

Please put the -testing branch through the kernel qa process. Btw I've
noticed that the nightly tests are missing a few recent i-g-t tests,
please upgrade that.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] I've got the RC6 bug

[Daniel Vetter]

On Wed, Jan 18, 2012 at 01:24:26AM +0100, Daniel Vetter wrote:
> On Wed, Jan 18, 2012 at 01:16:02AM +0100, CC wrote:
> > On Mon, Jan 16, 2012 at 5:36 PM, Daniel Vetter  wrote:
> > 
> > > On Mon, Jan 16, 2012 at 05:18:17PM +0100, CC wrote:
> > > > Hi,
> > > >
> > > > I've heard that you need users having the RC6 bug.
> > > >
> > > > I have the following setup:
> > > > CPU: Intel Core i5-2500K
> > > > Mainboard: ASRock Z68 Pro3-M
> > > > Memory: Corsair Vengeance CMZ8GX3M2A1866C9
> > > >
> > > > Although the CPU doesn't support VT-d, I disabled all virtualization
> > > > support in the UEFI setup.
> > > >
> > > > I use Arch Linux and Gnome 3 in the fallback mode. The problem is more
> > > > drastic without fallback mode, however.
> > > >
> > > > Whenever I enable RC6, I get the a few of these errors in dmesg:
> > > >
> > > > [   48.90] WARNING: at drivers/gpu/drm/i915/i915_drv.c:387
> > > > __gen6_gt_wait_for_fifo+0x94/0xa0 [i915]()
> > > > [   48.92] Hardware name: To Be Filled By O.E.M.
> > > > [   48.92] Modules linked in: ipv6 fuse ext2 snd_hda_codec_hdmi
> > > > snd_hda_codec_realtek mei(C) joydev r8169 shpchp pci_hotplug usbhid hid
> > > > snd_hda_intel iTCO_wdt mii iTCO_vendor_support i2c_i801 snd_hda_codec
> > > > processor snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc
> > > psmouse
> > > > serio_raw pcspkr evdev ext4 mbcache jbd2 crc16 xhci_hcd ehci_hcd usbcore
> > > > i915 drm_kms_helper drm intel_agp i2c_algo_bit button intel_gtt i2c_core
> > > > video sd_mod ahci libahci libata scsi_mod
> > > > [   48.900019] Pid: 623, comm: Xorg Tainted: GWC  3.1.9-2-ARCH 
> > > > #1
> > > > [   48.900020] Call Trace:
> > > > [   48.900023]  [] warn_slowpath_common+0x7f/0xc0
> > > > [   48.900025]  [] warn_slowpath_null+0x1a/0x20
> > > > [   48.900028]  [] __gen6_gt_wait_for_fifo+0x94/0xa0
> > > > [i915]
> > > > [   48.900032]  [] ring_write_tail+0x65/0x120 [i915]
> > > > [   48.900036]  [] render_ring_flush+0xbc/0xe0 [i915]
> > > > [   48.900040]  [] i915_gem_flush_ring+0x43/0x250
> > > [i915]
> > > > [   48.900044]  []
> > > > i915_gem_do_execbuffer.isra.7+0x1020/0x16d0 [i915]
> > > > [   48.900048]  [] i915_gem_execbuffer2+0x8b/0x240
> > > [i915]
> > > > [   48.900051]  [] drm_ioctl+0x3e4/0x4c0 [drm]
> > > > [   48.900053]  [] ? recalc_sigpending+0x1b/0x50
> > > > [   48.900057]  [] ? i915_gem_execbuffer+0x430/0x430
> > > > [i915]
> > > > [   48.900059]  [] ? fpu_finit+0x21/0x40
> > > > [   48.900061]  [] do_vfs_ioctl+0x8f/0x500
> > > > [   48.900063]  [] ? sys_rt_sigreturn+0x1eb/0x200
> > > > [   48.900064]  [] sys_ioctl+0x91/0xa0
> > > > [   48.900066]  [] system_call_fastpath+0x16/0x1b
> > > > [   48.900067] ---[ end trace 9a23b8b32b16a424 ]---
> > >
> > > This is a known side-effect of a dying gpu. It essentially means that the
> > > gpu refuses to wake up from deep-sleep states.
> > >
> > > > and then
> > > >
> > > > [   53.163526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> > > > elapsed... GPU hung
> > > > [   53.165046] [drm] capturing error event; look for more information in
> > > > /debug/dri/0/i915_error_state
> > > > [   53.177356] [drm:i915_wait_request] *ERROR* i915_wait_request returns
> > > > -11 (awaiting 1593 at 1592, next 1594)
> > > > [   53.181979] [drm:init_ring_common] *ERROR* render ring initialization
> > > > failed ctl  head  tail  start 
> > > > [   53.185522] [drm:init_ring_common] *ERROR* gen6 bsd ring
> > > initialization
> > > > failed ctl  head  tail  start 
> > > > [   53.188558] [drm:init_ring_common] *ERROR* blt ring initialization
> > > > failed ctl  head  tail  start 
> > > > [   55.330146] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> > > > elapsed... GPU hung
> > > > [   55.332202] [drm:i915_wait_request] *ERROR* i915_wait_request returns
> > > > -11 (awaiting 1594 at 1591, next 1595)
> > > > [   55.333258] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring
> > > > wedged!
> > > > [   55.333260] [drm:i915_reset] *ERROR* Failed to reset chip.
> > > >
> > > > Of course, I'd be willing to test out stuff. I'd need a bit of guide,
> > > > however.
> > >
> > > Can you please attach i915_error_state from debugfs (you need to retrigger
> > > the issue)? It contains a gpu dump which is useful to diagnose the bug.
> > >
> > > Yours, Daniel
> > > --
> > > Daniel Vetter
> > > Mail: dan...@ffwll.ch
> > > Mobile: +41 (0)79 365 57 48
> > >
> > 
> > I attached the error state.
> 
> Nice one, your gpu seems to have simply disappeared. And the ringbuffer
> contains a rather peculiar cmd sequence. Putting Chris (maybe he
> recognizes the pattern) and Ben (he's got a patch in the works to dump a
> debug register that might be interesting here) on cc. It's too late atm
> for me to think about this some more.

Chris and me looked some more at this one and it's a keeper. Can you
please file a bug report on bugs.freedesktop.org against drm/i91

Re: [Intel-gfx] I've got the RC6 bug

[Daniel Vetter]

On Fri, Jan 20, 2012 at 11:30:24AM +0100, Daniel Vetter wrote:
> On Wed, Jan 18, 2012 at 01:24:26AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 18, 2012 at 01:16:02AM +0100, CC wrote:
> > > On Mon, Jan 16, 2012 at 5:36 PM, Daniel Vetter  wrote:
> > > 
> > > > On Mon, Jan 16, 2012 at 05:18:17PM +0100, CC wrote:
> > > > > Hi,
> > > > >
> > > > > I've heard that you need users having the RC6 bug.
> > > > >
> > > > > I have the following setup:
> > > > > CPU: Intel Core i5-2500K
> > > > > Mainboard: ASRock Z68 Pro3-M
> > > > > Memory: Corsair Vengeance CMZ8GX3M2A1866C9
> > > > >
> > > > > Although the CPU doesn't support VT-d, I disabled all virtualization
> > > > > support in the UEFI setup.
> > > > >
> > > > > I use Arch Linux and Gnome 3 in the fallback mode. The problem is more
> > > > > drastic without fallback mode, however.
> > > > >
> > > > > Whenever I enable RC6, I get the a few of these errors in dmesg:
> > > > >
> > > > > [   48.90] WARNING: at drivers/gpu/drm/i915/i915_drv.c:387
> > > > > __gen6_gt_wait_for_fifo+0x94/0xa0 [i915]()
> > > > > [   48.92] Hardware name: To Be Filled By O.E.M.
> > > > > [   48.92] Modules linked in: ipv6 fuse ext2 snd_hda_codec_hdmi
> > > > > snd_hda_codec_realtek mei(C) joydev r8169 shpchp pci_hotplug usbhid 
> > > > > hid
> > > > > snd_hda_intel iTCO_wdt mii iTCO_vendor_support i2c_i801 snd_hda_codec
> > > > > processor snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc
> > > > psmouse
> > > > > serio_raw pcspkr evdev ext4 mbcache jbd2 crc16 xhci_hcd ehci_hcd 
> > > > > usbcore
> > > > > i915 drm_kms_helper drm intel_agp i2c_algo_bit button intel_gtt 
> > > > > i2c_core
> > > > > video sd_mod ahci libahci libata scsi_mod
> > > > > [   48.900019] Pid: 623, comm: Xorg Tainted: GWC  
> > > > > 3.1.9-2-ARCH #1
> > > > > [   48.900020] Call Trace:
> > > > > [   48.900023]  [] warn_slowpath_common+0x7f/0xc0
> > > > > [   48.900025]  [] warn_slowpath_null+0x1a/0x20
> > > > > [   48.900028]  [] __gen6_gt_wait_for_fifo+0x94/0xa0
> > > > > [i915]
> > > > > [   48.900032]  [] ring_write_tail+0x65/0x120 [i915]
> > > > > [   48.900036]  [] render_ring_flush+0xbc/0xe0 
> > > > > [i915]
> > > > > [   48.900040]  [] i915_gem_flush_ring+0x43/0x250
> > > > [i915]
> > > > > [   48.900044]  []
> > > > > i915_gem_do_execbuffer.isra.7+0x1020/0x16d0 [i915]
> > > > > [   48.900048]  [] i915_gem_execbuffer2+0x8b/0x240
> > > > [i915]
> > > > > [   48.900051]  [] drm_ioctl+0x3e4/0x4c0 [drm]
> > > > > [   48.900053]  [] ? recalc_sigpending+0x1b/0x50
> > > > > [   48.900057]  [] ? i915_gem_execbuffer+0x430/0x430
> > > > > [i915]
> > > > > [   48.900059]  [] ? fpu_finit+0x21/0x40
> > > > > [   48.900061]  [] do_vfs_ioctl+0x8f/0x500
> > > > > [   48.900063]  [] ? sys_rt_sigreturn+0x1eb/0x200
> > > > > [   48.900064]  [] sys_ioctl+0x91/0xa0
> > > > > [   48.900066]  [] system_call_fastpath+0x16/0x1b
> > > > > [   48.900067] ---[ end trace 9a23b8b32b16a424 ]---
> > > >
> > > > This is a known side-effect of a dying gpu. It essentially means that 
> > > > the
> > > > gpu refuses to wake up from deep-sleep states.
> > > >
> > > > > and then
> > > > >
> > > > > [   53.163526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> > > > > elapsed... GPU hung
> > > > > [   53.165046] [drm] capturing error event; look for more information 
> > > > > in
> > > > > /debug/dri/0/i915_error_state
> > > > > [   53.177356] [drm:i915_wait_request] *ERROR* i915_wait_request 
> > > > > returns
> > > > > -11 (awaiting 1593 at 1592, next 1594)
> > > > > [   53.181979] [drm:init_ring_common] *ERROR* render ring 
> > > > > initialization
> > > > > failed ctl  head  tail  start 
> > > > > [   53.185522] [drm:init_ring_common] *ERROR* gen6 bsd ring
> > > > initialization
> > > > > failed ctl  head  tail  start 
> > > > > [   53.188558] [drm:init_ring_common] *ERROR* blt ring initialization
> > > > > failed ctl  head  tail  start 
> > > > > [   55.330146] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> > > > > elapsed... GPU hung
> > > > > [   55.332202] [drm:i915_wait_request] *ERROR* i915_wait_request 
> > > > > returns
> > > > > -11 (awaiting 1594 at 1591, next 1595)
> > > > > [   55.333258] [drm:i915_reset] *ERROR* GPU hanging too fast, 
> > > > > declaring
> > > > > wedged!
> > > > > [   55.333260] [drm:i915_reset] *ERROR* Failed to reset chip.
> > > > >
> > > > > Of course, I'd be willing to test out stuff. I'd need a bit of guide,
> > > > > however.
> > > >
> > > > Can you please attach i915_error_state from debugfs (you need to 
> > > > retrigger
> > > > the issue)? It contains a gpu dump which is useful to diagnose the bug.
> > > >
> > > > Yours, Daniel
> > > > --
> > > > Daniel Vetter
> > > > Mail: dan...@ffwll.ch
> > > > Mobile: +41 (0)79 365 57 48
> > > >
> > > 
> > > I attached the error state.
> > 
> > Nice one, your gpu seems to have simply disappeared. And the ringbuffer
> > cont

Re: [Intel-gfx] [PATCH-v2 0/3] drm/i915: interlaced mode support

[Peter Ross]

On Wed, Jan 18, 2012 at 12:55:15PM -0800, Jesse Barnes wrote:
> On Wed, 18 Jan 2012 18:39:40 -0200
> Paulo Zanoni  wrote:
> 
> > Hi
> > 
> > 2012/1/18 Peter Ross :
> > > This patch set enables enables interlaced mode output on
> > > generation 3 and above chipsets.
> > 
> > I just tested that on HDMI.
> > 
> > The "interlace_allowed=1" patch seems fine: it made xrandr list more
> > modes. But I believe patch 1 is still not correct. I tested that and
> > instead of getting a 1920x1080 I got a 1920x1078 mode: vtotal, vblank
> > and vsync were wrong. If you look at the patch, you'll see that the
> > code has some "something -= 1" statements. I believe they could be
> > wrong.
> > 
> > So I removed these lines and tested again... Now the mode is actually
> > 1920x1080, but my monitor's OSD displays it as "1080p". So I also
> > tested my TV and it reported "1080p@25hz" too.
> > 
> > I guess we're still missing something... I'll try to debug.

Yep. I can confirm this problem too. With PATCH-v2, the output height
is reduced by two lines. (I used a test bitmap to count the lines on CRT)

> Yeah for the interlaced case the -1 should be after the multiply, if
> it's there at all...  would have to double check the docs.

The docs do suggest the timings need to be subtracted by one line.
Performing the -1 after the *2 fixes the problem, and this has been tested
on gen 3 and 4 chipsets.

When the -1 is removed altogether, the output is the visually identical
to when the -1 is present. I'm erring on the side of keeping the -1,
since that makes the implementation consistent with the documentation.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

[Intel-gfx] Moving 2D acceleration out of X driver into libdrm

[Stead, Alan]

Hello,
Does anyone have any thoughts on moving a lot of the 2D acceleration out of the 
X driver and into libdrm, this way it can be used by non-X drivers?
Thanks
Alan Stead
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Second Life / HD Graphics 3000 / Linux / OpenGL

[AW]

Hi!

I use Fedora Core 16 on an Intel Core i7-2600K...
Intel says, that HD Graphics 3000 can do OpenGL 3.0 (Wikipedia even says 3.1),
but: SecondLife complains about insufficient graphix support...
It refuses to do "Bump mapping and shiny", "Basic shaders",
"Atmospheric shaders", "Lighting and Shadows", "Ambient Occlusion", "Depth of
Field", "Shadows", "Water Reflections", and some others...

It is more stable and faster than my previous box (dual core, no HT),
but: I miss the shiny surfaces and the clear water... :-)

Should I use my old PCIe GPU card in the new box?
Or is there some trick (most "CPU"s are almost idle...)? :-)

Thx.

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

Re: [Intel-gfx] IVB Forcewake IRQ patches merged to drm-intel-fixes

[Keith Packard]

On Fri, 20 Jan 2012 10:35:07 +0100, Daniel Vetter  wrote:

> The last patch to revert the busy-loop w/a from Eric is missing your sob
> line. You can also add Acked-by: Daniel Vetter  to
> it if you want.

Thanks! I've updated the drm-intel-fixes branch.

-- 
keith.pack...@intel.com


pgp2F8XhUx6no.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 1/2] drm/i915: Remove the MI_FLUSH_ENABLE setting.

[Eric Anholt]

On Thu, 19 Jan 2012 10:59:57 -0800, Ben Widawsky  wrote:
> On 01/19/2012 10:54 AM, Keith Packard wrote:
> > On Thu, 19 Jan 2012 10:50:05 -0800, Eric Anholt  wrote:
> > 
> >> -  if (IS_GEN6(dev) || IS_GEN7(dev))
> >> -  mode |= MI_FLUSH_ENABLE << 16 | MI_FLUSH_ENABLE;
> > 
> > This seems better than setting random bits that don't do anything but
> > annoy the simulator.
> 
> The simulator complains unless both bits are set iirc. I can double
> check, but it's been a while since I've run without my patch.

Can you please cite the message you're getting?  I've read a lot of the
simulator at this point, particularly pieces relating to flushing, and I
can't find what you're talking about.


pgpa4jiuT14ZB.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: clarify gen2 pageflip cmd

[Eric Anholt]

On Fri, 20 Jan 2012 10:43:44 +0100, Daniel Vetter  
wrote:
> I've reviewed gen2 pageflip code do hunt down multple prepare pageflip
> issues. The only thing I've found is a slight but functionally
> meaningless confusion about the length of the mi cmd.
> 
> Fix it up and add a comment about what this dword should be (according
> to docs at least).
> 
> Signed-Off-by: Daniel Vetter 

Reviewed-by: Eric Anholt 


pgpgsAj8FmEgo.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Moving 2D acceleration out of X driver into libdrm

[Eric Anholt]

On Fri, 20 Jan 2012 17:46:59 +, "Stead, Alan"  wrote:
> Hello,
> Does anyone have any thoughts on moving a lot of the 2D acceleration
> out of the X driver and into libdrm, this way it can be used by non-X
> drivers?

The goal is not to move it out, it's to delete it and just use GL.


pgpL9BTOfBjI1.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Second Life / HD Graphics 3000 / Linux / OpenGL

[Eric Anholt]

On Fri, 20 Jan 2012 10:00:45 -0800 (PST), AW  wrote:
> Hi!
> 
> I use Fedora Core 16 on an Intel Core i7-2600K...
> Intel says, that HD Graphics 3000 can do OpenGL 3.0 (Wikipedia even says 3.1),
> but: SecondLife complains about insufficient graphix support...
> It refuses to do "Bump mapping and shiny", "Basic shaders",
> "Atmospheric shaders", "Lighting and Shadows", "Ambient Occlusion", "Depth of
> Field", "Shadows", "Water Reflections", and some others...
> 
> It is more stable and faster than my previous box (dual core, no HT),
> but: I miss the shiny surfaces and the clear water... :-)

Someone would have to take a look into what SL is testing to decide that
the hardware can't do what it wants.  MESA_GLSL=dump can sometimes get
you information about shaders they tried to compile that failed for some
reason (often due to shaders being invalid even though some other driver
passed them through).  Or it may be that they just want a higher version
of GL -- Mesa 8.0, with float textures enabled, exposes 3.0 on gen6.


pgpdOM9qye4QS.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Second Life / HD Graphics 3000 / Linux / OpenGL

[AW]

The Imprudence Secondlife Viewer complains about the graphix capabilities, 
too...
but: later it just does reflections/water/shininess right (no disabled graphix 
features like in the official SL viewer)...
but:
1. Imprudence produces just 15fps with all CPUs <50%... and intel_gpu_top 
showing nothing above 65%...
2. and it is still version 1, while linden's Viewer is version 2...

> Someone would have to take a look into what SL is testing to decide that
>
i think it just checks the "GL info string"s... 
|2012-01-20T21:10:04Z INFO: printGLInfoString: GL_VENDOR: Tungsten Graphics, Inc
|2012-01-20T21:10:04Z INFO: printGLInfoString: GL_RENDERER: Mesa DRI Intel(R)
|Sandybridge Desktop 
|2012-01-20T21:10:04Z INFO: printGLInfoString: GL_VERSION: 2.1 Mesa 7.11.2
|2012-01-20T21:10:04Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
Just so you know, your computer does not meet Second Life's minimum system
requirements. You may experience poor performance. Unfortunately, the Second
Life Support Portal can't provide technical support for unsupported system
configurations.


When I try to restart SL after a shader-less session,
it fails and I get this error message:
|2012-01-20T21:54:07Z WARNING: createContext: createContext:
|window creation failure. SDL: Couldn't find matching GLX visual
I have to remove the user_settings/settings.xml before I can start it again...

Although i setenv'd MESA_GLSL to "dump" and then to "log" I saw no special 
output
and no new files in the work directory...

I think i will ask the Lindens if they want to make their viewer more 
Mesa-friendly... :-)

-arne

___
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: Remove the MI_FLUSH_ENABLE setting.

[Ben Widawsky]

On 01/20/2012 11:16 AM, Eric Anholt wrote:
> On Thu, 19 Jan 2012 10:59:57 -0800, Ben Widawsky  wrote:
>> On 01/19/2012 10:54 AM, Keith Packard wrote:
>>> On Thu, 19 Jan 2012 10:50:05 -0800, Eric Anholt  wrote:
>>>
 -  if (IS_GEN6(dev) || IS_GEN7(dev))
 -  mode |= MI_FLUSH_ENABLE << 16 | MI_FLUSH_ENABLE;
>>>
>>> This seems better than setting random bits that don't do anything but
>>> annoy the simulator.
>>
>> The simulator complains unless both bits are set iirc. I can double
>> check, but it's been a while since I've run without my patch.
> 
> Can you please cite the message you're getting?  I've read a lot of the
> simulator at this point, particularly pieces relating to flushing, and I
> can't find what you're talking about.
> 

It is not email friendly paste.

Gen7GT/Render/src/CsMiCommonCatcher.cpp +293

It links to a power point which shows the workaround is to set both
bits. The powerpoint is kind enough to crash libreoffice for me.

Ben

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

Re: [Intel-gfx] Moving 2D acceleration out of X driver into libdrm

[Clemens Eisserer]

Hi,

>> Does anyone have any thoughts on moving a lot of the 2D acceleration
>> out of the X driver and into libdrm, this way it can be used by non-X
>> drivers?
>
> The goal is not to move it out, it's to delete it and just use GL.

Now that SNA is finally almost stable and really fast, revert
everything and go back to the dark age intel users had to live with
for so long? ;)
Seriously, every time when there were huge steps a lot of stuff
regressed (XAA/EXA/UXA/SNA) - and that happend quite often in the last
few years. I now if I am prepared for another round just yet...

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

Re: [Intel-gfx] Moving 2D acceleration out of X driver into libdrm

[Eugeni Dodonov]

On Fri, Jan 20, 2012 at 21:10, Clemens Eisserer wrote:

> Hi,
>
> >> Does anyone have any thoughts on moving a lot of the 2D acceleration
> >> out of the X driver and into libdrm, this way it can be used by non-X
> >> drivers?
> >
> > The goal is not to move it out, it's to delete it and just use GL.
>
> Now that SNA is finally almost stable and really fast, revert
> everything and go back to the dark age intel users had to live with
> for so long? ;)
> Seriously, every time when there were huge steps a lot of stuff
> regressed (XAA/EXA/UXA/SNA) - and that happend quite often in the last
> few years. I now if I am prepared for another round just yet...
>

Don't forget that there is Glamor now as well :).

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

Re: [Intel-gfx] Moving 2D acceleration out of X driver into libdrm

[Stead, Alan]

On Friday, January 20, 2012 11:51 AM, Eric Anholt [mailto:e...@anholt.net]
wrote:
> > Hello,
> > Does anyone have any thoughts on moving a lot of the 2D acceleration
> > out of the X driver and into libdrm, this way it can be used by non-X
> > drivers?
> 
> The goal is not to move it out, it's to delete it and just use GL.

Do you know what direction OTC plans to take with respect to video post
processing?

Thanks
Alan Stead


smime.p7s
Description: S/MIME cryptographic signature
___
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: Remove the MI_FLUSH_ENABLE setting.

[Eric Anholt]

On Fri, 20 Jan 2012 14:57:44 -0800, Ben Widawsky  wrote:
> On 01/20/2012 11:16 AM, Eric Anholt wrote:
> > On Thu, 19 Jan 2012 10:59:57 -0800, Ben Widawsky  wrote:
> >> On 01/19/2012 10:54 AM, Keith Packard wrote:
> >>> On Thu, 19 Jan 2012 10:50:05 -0800, Eric Anholt  wrote:
> >>>
>  -if (IS_GEN6(dev) || IS_GEN7(dev))
>  -mode |= MI_FLUSH_ENABLE << 16 | MI_FLUSH_ENABLE;
> >>>
> >>> This seems better than setting random bits that don't do anything but
> >>> annoy the simulator.
> >>
> >> The simulator complains unless both bits are set iirc. I can double
> >> check, but it's been a while since I've run without my patch.
> > 
> > Can you please cite the message you're getting?  I've read a lot of the
> > simulator at this point, particularly pieces relating to flushing, and I
> > can't find what you're talking about.
> > 
> 
> It is not email friendly paste.
> 
> Gen7GT/Render/src/CsMiCommonCatcher.cpp +293
> 
> It links to a power point which shows the workaround is to set both
> bits. The powerpoint is kind enough to crash libreoffice for me.

That block is checking exactly one bit, bit 12, in my tree.


pgp1lsYfeENBb.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 1/2] drm/i915: Remove the MI_FLUSH_ENABLE setting.

[Ben Widawsky]

 Original message 
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove the MI_FLUSH_ENABLE 
setting. 
From: Eric Anholt  
To: Ben Widawsky  
CC: Keith Packard ,intel-gfx@lists.freedesktop.org 

On Fri, 20 Jan 2012 14:57:44 -0800, Ben Widawsky  wrote:
> On 01/20/2012 11:16 AM, Eric Anholt wrote:
> > On Thu, 19 Jan 2012 10:59:57 -0800, Ben Widawsky  wrote:
> >> On 01/19/2012 10:54 AM, Keith Packard wrote:
> >>> On Thu, 19 Jan 2012 10:50:05 -0800, Eric Anholt  wrote:
> >>>
>  - if (IS_GEN6(dev) || IS_GEN7(dev))
>  - mode |= MI_FLUSH_ENABLE << 16 | MI_FLUSH_ENABLE;
> >>>
> >>> This seems better than setting random bits that don't do anything but
> >>> annoy the simulator.
> >>
> >> The simulator complains unless both bits are set iirc. I can double
> >> check, but it's been a while since I've run without my patch.
> > 
> > Can you please cite the message you're getting?  I've read a lot of the
> > simulator at this point, particularly pieces relating to flushing, and I
> > can't find what you're talking about.
> > 
> 
> It is not email friendly paste.
> 
> Gen7GT/Render/src/CsMiCommonCatcher.cpp +293
> 
> It links to a power point which shows the workaround is to set both
> bits. The powerpoint is kind enough to crash libreoffice for me.

That block is checking exactly one bit, bit 12, in my tree.

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

Re: [Intel-gfx] Updated -next

[Sun, Yi]

> Hi all,
> 
> Not much in the first -next update under the new process, I'd like to
> tests the qa process first. Highligths:
> - first part of i9xx_crtc_mode_set refactor from Jesse
> - quite a few ajax-is-paranoid patches
> - HAS_LLC param from Eugeni
> - kill i915_mem.c
> 
> For easier testing there's also an updated drm-intel-testing branch with
> the latest -fixes merged in (i.e. the missed irq patches). Testing
> feedback highly welcome.
> 
> Hi Yi,
> 
> Please put the -testing branch through the kernel qa process. Btw I've
> noticed that the nightly tests are missing a few recent i-g-t tests,
> please upgrade that.
> 

Hi Daniel,

I'm confused about branch drm-intel-testing. Does it mean drm-intel-next branch 
when you said branch drm-intel-testing?

Thank you for finding the issue in nightly tests, I'll work it out soon.

By the way, we will be in vacation till Jan 30th.

Thanks 
  --Sun Yi

> Cheers, Daniel
> --
> Daniel Vetter
> Mail: dan...@ffwll.ch
> Mobile: +41 (0)79 365 57 48
___
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: Remove the MI_FLUSH_ENABLE setting.

[Ben Widawsky]

On 01/20/2012 04:40 PM, Eric Anholt wrote:
> On Fri, 20 Jan 2012 14:57:44 -0800, Ben Widawsky  wrote:
>> On 01/20/2012 11:16 AM, Eric Anholt wrote:
>>> On Thu, 19 Jan 2012 10:59:57 -0800, Ben Widawsky  wrote:
 On 01/19/2012 10:54 AM, Keith Packard wrote:
> On Thu, 19 Jan 2012 10:50:05 -0800, Eric Anholt  wrote:
>
>> -if (IS_GEN6(dev) || IS_GEN7(dev))
>> -mode |= MI_FLUSH_ENABLE << 16 | MI_FLUSH_ENABLE;
>
> This seems better than setting random bits that don't do anything but
> annoy the simulator.

 The simulator complains unless both bits are set iirc. I can double
 check, but it's been a while since I've run without my patch.
>>>
>>> Can you please cite the message you're getting?  I've read a lot of the
>>> simulator at this point, particularly pieces relating to flushing, and I
>>> can't find what you're talking about.
>>>
>>
>> It is not email friendly paste.
>>
>> Gen7GT/Render/src/CsMiCommonCatcher.cpp +293
>>
>> It links to a power point which shows the workaround is to set both
>> bits. The powerpoint is kind enough to crash libreoffice for me.
> 
> That block is checking exactly one bit, bit 12, in my tree.

Hmm, it appears I had some PEBPAC (phone and chair). I sent two earlier
emails, and the semi-useful one never seemed to make it. Well this gives
me a chance to elaborate anyway.

You have to read the powerpoint. In there it says to set both bits. It
looks like I was incorrect about the simulator itself caring, that
indeed only checks for bit 12. I think it's all moot anyway, as it
appears bit 12 (with or without bit 11) doesn't play nice with IVB.

To sum up there are three options
Bit 11, wrong in docs, wrong in simulator, wrong in ppt; doesn't hang
Bit 12, right in docs, right in simulator, wrong in ppt; hangs (I think)
Bit 11|12, sorta wrong/right in docs an simulator, right in ppt; hangs

And I honestly don't care which we go with if the simulator logs don't
tell me everytime that bit 12 wasn't set.

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