On Fri, 20 Jul 2012 18:02:28 +0100
Chris Wilson wrote:
> The requirements for the sync flush to be emitted prior to the render
> cache flush is only true for SandyBridge. On IvyBridge and friends we
> can just emit the flushes with an inline CS stall.
>
> Signed-off-by: Chris Wilson
Tested-by:
Hi,
I am using a Core i5-3475S on a ASUS P8H77-I. The system is connected
to my amp through HDMI. For some reason I cannot get passthrough of
DTS-HD MA or Dolby TrueHD to work properly. On my HTPC with an ION2
chipset I can use
aplay -D hdmi:CARD=NVidia,DEV=2,AES0=6 -c8 -fs16_le -r192000 dtshd_te
On Fri, Jul 20, 2012 at 10:01:03AM -0700, Eric Anholt wrote:
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > index 3f98137..3b62952 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > @@ -972,
Add the host bridge ID used by the simulator. This was added in a
previous patch for the agp layer, but wasn't preserved here. It also
gives us an opportunity to let the rest of the driver know we're running
as the simulator for various workarounds.
We must always do this early as it's the only w
Forcewake isn't implemented on the simulator, and doing the dance is
problematic. I haven't really root-caused it, but something in the chain
detects the polling of the ack register, and the system grinds to a
halt.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/
Olivier Galibert writes:
> Shaders, piglit test ones in particular, may write only to one of
> gl_FrontColor/gl_BackColor. The standard is unclear on whether the
> behaviour is defined in that case, but it seems reasonable to support
> it.
>
> The choice done there to pick up whichever color was
The requirements for the sync flush to be emitted prior to the render
cache flush is only true for SandyBridge. On IvyBridge and friends we
can just emit the flushes with an inline CS stall.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 33 +++---
Am 20.07.2012 17:10, schrieb Adam Jackson:
autoconf bug! Nice find.
I think the test for "-fPIC" support is fundamentally
broken and should be fixed. Or would it be better
to check for -v and --verbose in CFLAGS?
It sounds like the test is broken, yeah. Although I wonder how many other
st
On 7/20/12 8:03 AM, Knut Petersen wrote:
Am 18.07.2012 16:29, schrieb Adam Jackson:
So this really honestly is a toolchain problem, not a driver problem.
Neither icecream nor gcc are broken.
The solution is pretty simple:
Never ever include -v or --verbos
On Thu, Jul 19, 2012 at 02:20:11PM +0200, Thomas Richter wrote:
> Hi Daniel,
>
> >>As a side question, have you been able to look into the video
> >>overlay hang I reported lately? I haven't
> >>had the time yet to update the i915 driver from the latest
> >>repository, but the version from three w
On Wed, Jul 11, 2012 at 04:27:57PM +0200, Daniel Vetter wrote:
> With the base addresses shifting around, this is easier to handle.
> Also move to the real reg offset on vlv.
>
> Signed-off-by: Daniel Vetter
I've merged this for -next with Chris' irc-ack.
-Daniel
--
Daniel Vetter
Mail: dan...@ff
On Wed, Jul 11, 2012 at 04:27:55PM +0200, Daniel Vetter wrote:
> Will be used more in the next patch.
>
> Signed-off-by: Daniel Vetter
Jesse's not around to ack this and Paulo punted. So I've just merged this.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c |2 +-
> drivers/gpu/drm/i915/i9
Am 18.07.2012 16:29, schrieb Adam Jackson:
So this really honestly is a toolchain problem, not a driver problem.
Neither icecream nor gcc are broken.
The solution is pretty simple:
Never ever include -v or --verbose in CFLAGS
==
Just fixup the patch title: s/inte_crt/intel_crtl/
On Wed, 11 Jul 2012 16:27:57 +0200, Daniel Vetter
wrote:
> With the base addresses shifting around, this is easier to handle.
> Also move to the real reg offset on vlv.
+1
> Signed-off-by: Daniel Vetter
Acked-by: Chris Wilson
-Chris
--
Ch
Request preallocation was added to i915_add_request() in order to
support the overlay. However, not all users care and can quite happily
ignore the failure to allocate the request as they will simply repeat
the request in the future.
By pushing the allocation down into i915_add_request(), we can t
As we move to lazily clearing the GPU write domain only when the buffer
becomes inactive, this leaves a window of opportunity for
i915_gem_object_pin_to_display_plane() to detect a seemingly
inconsistent value. This function is special as it tries to pipeline the
operation to avoid the stall and so
As we always flush the GPU cache prior to emitting the breadcrumb, we no
longer have to worry about the deferred flush causing the
pending_gpu_write to be delayed. So we can instead utilize the known
last_write_seqno to hopefully minimise the wait times.
Signed-off-by: Chris Wilson
---
drivers/g
Otherwise once we use the buffer with a BLT command on gen2/3, we will
always regard future command submissions as continuing the fenced
access. However, now that we flush/invalidate between every batch we can
drop this pessimism.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_exe
As we guarantee to emit a flush before emitting the breadcrumb or
the next batchbuffer, there is no further need for the flushing list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c |7
drivers/gpu/drm/i915/i915_drv.h | 19 +++
drivers/gpu/drm/i91
This is now handled by a global flag to ensure we emit a flush before
the next serialisation point (if we failed to queue one previously).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|2 --
drivers/gpu/drm/i915/i915_gem.c| 53 +
Rely instead on the insertion of the implicit flush before the seqno
breadcrumb.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_ge
By moving the function to intel_ringbuffer and currying the appropriate
parameter, hopefully we make the callsites easier to read and
understand.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|3 ---
drivers/gpu/drm/i915/i915_gem.c| 29 +++--
Now that we unconditionally flush and invalidate between every batch
buffer, we no longer need the complex logic to decide which domains
require flushing. Remove it and rejoice.
One side-effect is that this also removes the broken wait-on-pending-flip
logic.
Signed-off-by: Chris Wilson
---
driv
As the flush is either performed explictly immediately after the
execbuffer dispatch, or before the serialisation of last_fenced_seqno we
can forgo the explict i915_gem_flush_ring().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 16 ++--
1 file changed, 2 insert
Fresh set of patches haven beaten the previous series into submission.
Just a couple of bug fixes since then (fallout from kcalloc -> kmalloc,
and a potential BUG_ON after using semaphores) and rebased.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.f
Laurent Pinchart missed this when sending in is giant constify patch:
commit e811f5ae19043b2ac2c28e147a4274038e655598
Author: Laurent Pinchart
Date: Tue Jul 17 17:56:50 2012 +0200
drm: Make the .mode_fixup() operations mode argument a const pointer
Signed-Off-by: Daniel Vetter
---
drive
On Fri, Jul 20, 2012 at 12:51:41AM +0200, Carsten Emde wrote:
> On 07/19/2012 04:40 PM, Daniel Vetter wrote:
> >Well, the backlight-confusion branch had a bug and outright disabled
> >the intel backlight :( drm-intel-next-queued should have fixes for all
> >the backlight goofus I've accidentally cr
27 matches
Mail list logo
