On Thu, Sep 09, 2021 at 01:33:23PM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 10:59:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > > >
On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > >
On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > > >
")
> > @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice
> > Lake 6x8 GT1.5)")
> > CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> > CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x
observe here.
> Does the attached patch also fix the problem with the
> older intel chip you originally reported?
Seems to. Thanks for tracking it down.
Tested-by: Ville Syrjälä
>
> Thanks!
>
> Mathias
> From 68e921478c8c38a13b7258e0d3f1f235709dcfe9 Mon Sep 17 00:00:00
at problem using classic swrast.
> Some variants of last weeks git master show the exact same
> pictures than swrast using the last good commit from your bisect.
> So, basically I can't reproduce the problem here.
Looks like
"vid_gl20" "0"
is needed to reproduce th
ed color on it but now it has green.
It looked like there's already a bunch of stuff piled on top of the
regression so reverting didn't seem entirely trivial, and thus I didn't
bother trying.
--
Ville Syrjälä
Intel
___
mesa-dev
,
> display_mode->vsync_end = x_mode->vsync_end;
> display_mode->vtotal = x_mode->vtotal;
> display_mode->vscan = 0;
> - if (x_mode->mode_flags & XCB_RANDR_MODE_FLAG_DOUBLE_SCAN)
> - display_mode->vscan = 1;
> display_mode->flag
On Fri, May 11, 2018 at 03:26:57PM +0100, Eric Engestrom wrote:
> On Monday, 2018-05-07 20:05:40 +0300, Ville Syrjälä wrote:
> > From: Ville Syrjälä
> >
> > platform_x11 with dri3 needs inc_loader.
> >
> > In file included from ../src/egl/drivers/dri2/platfor
"that's a kernel bug".
Old kernels required TILING_X with MOD_X. I changed that at some
point to allow TILING_NONE with any modifier, but otherwise we
require the BO tiling to match the modifier. Ie. you still can't
mix TILING_Y + MOD_X for example.
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
forms don't
support the HDR infoframe, so the display wouldn't know what to do
with the data you're feeding it.
As for the future, right now I don't really have any solid plans on
continuing to develop this. I might dabble with it a bit more out of
curiosity, but I&#
s for fun). I can't remmeber if I ever properly tested the
L3+LLC=UC combination on other platforms though.
Also there's no way to flush L3. You can flush/invalidate caches that
may or may not be backed by L3. And we do seem to flush/invalidate all
of them. IIRC we were missing the data cache flush bit from the
PIPE_CONTROL at some point, but now it seems to be there. Also I
doubt the data cache would be involved in your typical render
target accesses.
The spec does say that if something gets evicted from L3 it may end up
in LLC even if LLC cacheability is UC. I assume that must be talking
about the data cache since IIRC that is the only RW cache backed by L3,
and I can't see why evicting something from a RO cache would end up
anywhere.
So if we don't have to worry about the eviction issue I think always
using L3 is the correct answer.
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Oct 17, 2017 at 09:00:56PM +0200, Nicolai Hähnle wrote:
> On 17.10.2017 16:09, Ville Syrjälä wrote:
> > On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 02:22 PM, Daniel Vetter wrote:
> >>> On Tue, Oct 17, 2017 at 12:28:1
27;t
> be that hard.
Apart from the actual implementation hurdles it does open up some new questions:
- Is it going to be per-plane or per-crtc?
- What happens if the target timestamp is already stale?
- What happens if the target timestamp is good when it gets scheduled,
but can't be met
On Thu, Oct 12, 2017 at 01:51:24PM -0700, Dylan Baker wrote:
> Both patches are:
> Reviewed-by: Dylan Baker
Thanks guys. Pushed.
>
> Quoting Ville Syrjala (2017-10-12 09:34:55)
> > From: Ville Syrjälä
> >
> > Build i915 with meson. More or less copied from i
in this patch, and clean up
some further patches to fix this stuff properly for i915.
>
> On Fri, 2017-06-23 at 14:58 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Pass the correct src coordinates to CopyTexSubImage()
> > when creat
On Fri, Jun 23, 2017 at 06:43:37PM -0700, Ian Romanick wrote:
> On 06/23/2017 04:58 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Pass the correct src coordinates to CopyTexSubImage()
> > when creating the temporary texture, and also take ca
On Thu, Jun 22, 2017 at 03:43:36PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 21, 2017 at 03:13:22PM -0700, Ian Romanick wrote:
> > On 06/21/2017 10:38 AM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > gl_FragCoord contains the
On Wed, Jun 21, 2017 at 03:13:22PM -0700, Ian Romanick wrote:
> On 06/21/2017 10:38 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > gl_FragCoord contains the window coordinates so it seems to me that
> > we should not use perspective corre
On Tue, Jun 20, 2017 at 11:00:52AM -0700, Ian Romanick wrote:
> Reviewed-by: Ian Romanick
Thanks. Pushed to master.
>
> On 06/20/2017 10:22 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Unlike the older gen2 hardware, gen3 perfo
On Sun, Jun 18, 2017 at 07:07:51PM -0700, Ian Romanick wrote:
> From: Ian Romanick
I have the same patch in my tree :)
For the i915 parts of the series:
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 5 ++
On Wed, Jun 14, 2017 at 11:45:17AM +0100, Emil Velikov wrote:
> Hi Ville
>
> On 5 June 2017 at 15:52, wrote:
> > From: Ville Syrjälä
> >
> > wpos_tex used to be a GLuint so assinging -1 to it and
> > later comparing with -1 worked correctly, but commit
> &g
t; >
> >
> > So you think it will work if we use "(const VkExtent3D) { 1, 1, 1 }"?
>
> Yep, that's my guess.
Pretty sure I tried that for the format stuff. Didn't work IIRC.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Nov 29, 2016 at 08:54:26AM -0800, Jason Ekstrand wrote:
> On Tue, Nov 29, 2016 at 8:47 AM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
> > On Tue, Nov 29, 2016 at 08:28:55AM -0800, Jason Ekstrand wrote:
> > > On Tue, Nov 29, 2016 at 1:23 AM, wr
On Tue, Nov 29, 2016 at 08:28:55AM -0800, Jason Ekstrand wrote:
> On Tue, Nov 29, 2016 at 1:23 AM, wrote:
>
> > From: Ville Syrjälä
> >
> > Set the include paths to consider in-tree headers before out-of-tree
> > headers.
> >
> > Avoids the build fai
and
> pushed the change. Thanks for fixing it again.
>
> Reviewed-by: Jason Ekstrand
Thanks. Pushed.
>
> On Sep 30, 2016 1:00 PM, wrote:
>
> > From: Ville Syrjälä
> >
> > gcc-4 and earlier don't allow compound literals where a constant
> > is
ers.
> > +*/
> > + GBM_BO_USE_SCANOUT_ROTATION_90 = (1 << 5),
> > + GBM_BO_USE_SCANOUT_ROTATION_180 = (1 << 6),
> > + GBM_BO_USE_SCANOUT_ROTATION_270 = (1 << 7),
> > };
>
> Hmm, we should probably explicitly specify the orientation of the 90 and
> 270 degree rotations. Clockwise? (Same in patch 1)
kms (and xrandr) are ccw.
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Oct 23, 2015 at 06:25:55PM -0700, Vivek Kasireddy wrote:
> On Fri, 23 Oct 2015 15:29:08 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Oct 23, 2015 at 12:18:39PM +0900, Michel Dänzer wrote:
> > > On 23.10.2015 10:44, Vivek Kasireddy wrote:
> > > > For ce
in/gbm.h
> > @@ -213,6 +213,11 @@ enum gbm_bo_flags {
> > * Buffer is linear, i.e. not tiled.
> > */
> > GBM_BO_USE_LINEAR = (1 << 4),
> > + /**
> > + * Buffer would be rotated and some platforms have additional tiling
> > +* requireme
On Tue, Oct 20, 2015 at 02:02:21PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 20, 2015 at 08:15:32AM +, Predut, Marius wrote:
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Monday, October 19, 2015 6:
On Tue, Oct 20, 2015 at 08:15:32AM +, Predut, Marius wrote:
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Monday, October 19, 2015 6:04 PM
> > To: Predut, Marius
> > Cc: mesa-dev@lists.freedesktop.org; Iago
On Thu, Oct 15, 2015 at 06:03:34PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 15, 2015 at 02:19:09PM +, Predut, Marius wrote:
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Wednesday, October 07,
On Thu, Oct 15, 2015 at 02:19:09PM +, Predut, Marius wrote:
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Wednesday, October 07, 2015 1:53 PM
> > To: Predut, Marius
> > Cc: mesa-dev@lists.freedesktop.
h and BTW, the gen4/5 line width handling in i965 looks busted too
(only gen6+ got fixed).
> lis4 |= width << S4_LINE_WIDTH_SHIFT;
>
> if (lis4 != i915->state.Ctx[I915_CTXREG_LIS4]) {
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> me
On Sat, Oct 03, 2015 at 02:55:57AM +0800, Chih-Wei Huang wrote:
> 2015-05-22 1:21 GMT+08:00 Ville Syrjälä :
> > On Sat, May 16, 2015 at 01:36:44AM +0800, Chih-Wei Huang wrote:
> >> 2015-04-13 19:00 GMT+08:00 Ville Syrjälä :
> >>
> >> Glad to see the patches to
; + switch (cpp) {
> > + case 1:
> > + *tile_h = 64 * cpp;
>
> I'm still reading the docs for the non-legay tiling formats Yf, and Ys.
> So I can't comment on this part of the patch.
As it turns out I was just looking at Yf and whatnot from displa
; else {
> > - ok = HAVE_TRIANGLES; /* flatshading is ok. */
> > + ok = HAVE_TRIANGLES && (count % 4 == 0); /* flatshading is ok. */
> > }
> > break;
> >default:
> >
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
;hw_bt_pool.next_offset);
> ADVANCE_BATCH();
>
> /* Disable the TE */
> @@ -101,7 +101,7 @@ disable_stages(struct brw_context *brw)
>
> BEGIN_BATCH(2);
> OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_DS << 16 | (2 - 2));
> - OUT_BATCH(0);
> +
hung my system.
>
> I guess the reason for this is that MI_SET_CONTEXT is not used in GEN8
> anymore? I found these comments and quoting from the docs in intel_lrc.c:
>
> "Instead of the legacy MI_SET_CONTEXT, the way you tell the
On Fri, May 15, 2015 at 12:06:54PM -0700, Ian Romanick wrote:
> On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > No driver supports elts currently, and these make the validate_render
> > code a bit hard to follow. Just ki
On Thu, May 21, 2015 at 09:14:03PM +0300, Ville Syrjälä wrote:
> On Fri, May 15, 2015 at 12:18:11PM -0700, Ian Romanick wrote:
> > There are some really twitchy tests in ES1 (and possibly ES2)
> > conformance related to this. Do any of those tests change with this commit?
>
&g
hem on
PNV.
>
> On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The sub-pixel adjustment for points was killed off in
> > commit 60d762aa625095a8c1f9597d8530bb5a6fa61b4c
> > Author: Xiang, Haihao
> > Date: W
On Fri, May 15, 2015 at 12:08:33PM -0700, Ian Romanick wrote:
> On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When rendering quad strips via tri strips we can't get the provoking
> > vertex right, so disallow flat sh
On Fri, May 15, 2015 at 12:07:54PM -0700, Ian Romanick wrote:
> On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We can allow rendering flat shaded polygons using tri fans if we check
> > the provoking vertex convention.
On Thu, Apr 16, 2015 at 11:20:01AM -0700, Kenneth Graunke wrote:
> On Thursday, April 16, 2015 09:00:46 PM ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > All CHV devices will be branded as "Intel(r) HD Graphics".
> >
> > Signed-
On Mon, Mar 23, 2015 at 02:47:16PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I've had some of these i915 patches lying around for half a year or more,
> so I figured it's time to post them.
>
> This series fixes rendering problems in g
On Thu, Mar 05, 2015 at 01:48:29PM -0800, Kenneth Graunke wrote:
> On Thursday, March 05, 2015 07:41:29 PM Ville Syrjälä wrote:
> > On Fri, Jan 23, 2015 at 12:12:56PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > >
On Thu, Mar 05, 2015 at 11:40:16AM -0800, Matt Turner wrote:
> On Thu, Mar 5, 2015 at 11:32 AM, wrote:
> > From: Ville Syrjälä
>
> I committed a patch a little while ago from Mark to fix this (as
> commit 5f9ee6a0).
Yep see it now. I must have fetched more or less just be
On Fri, Jan 23, 2015 at 12:12:56PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Increase the device info .urb.size for CHV to match the default URB
> size (192kB).
>
> Signed-off-by: Ville Syrjälä
Ping?
> ---
> src/mesa/drivers/dri/i965/brw_d
On Wed, Jan 21, 2015 at 12:51:02PM -0800, Kenneth Graunke wrote:
> On Wednesday, January 21, 2015 08:17:36 PM ville.syrj...@linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Increase the device info .urb.size for BDW GT3 and CHV to match the
> > default UR
On Wed, Jan 21, 2015 at 12:51:02PM -0800, Kenneth Graunke wrote:
> On Wednesday, January 21, 2015 08:17:36 PM ville.syrj...@linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Increase the device info .urb.size for BDW GT3 and CHV to match the
> > default UR
in bspec about this bit. Can't see anything suspicious
in the w/a database either. So I guess we can assume it's safe.
Reviewed-by: Ville Syrjälä
But I do wonder a bit if there's any relationship with the WIZ hashing
mode. Looks like we've not brought the 16x4 WIZ hashing mod
want to run it and make sure it still
works correctly on gen8. Here's the test:
http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/35399
> /* Improve HiZ throughput on CHV. */
> WA_SET_BIT_MASKED(HIZ_CHICKEN, CHV_HZ_8X8_MODE_IN_1X);
>
&
; > It's not my call, it's just nice to have platform specific bisection. And
> > > the
> > > patch wasn't on the list, it was the one I kept asking you to look at in
> > > my
> > > branch :-)
> > >
> > > > > I haven't looked at Broadwell docs, so I'll let someone else take
> > > > > care of that.
> > > > >
> > > > > I don't know if I agree with Chris that we should call these in the
> > > > > workaround
> > > > > section, but whatever. init_clock_gating is equally sucky.
> > > >
> > > > init_clock_gating doesn't work. The register writes don't stick and
> > > > they have
> > > > no effect at all. Setting them here makes them actually take effect in
> > > > the
> > > > context.
> > > >
> > > > --Ken
> > >
> > > Separate thread now, but are you sure? We're setting at least two context
> > > specific registers in there today, among them: GEN7_FF_THREAD_MODE (which
> > > is
> > > important to performance).
> >
> > It looks like we're setting:
> > - [BDW] RC_SLEEP_PSMI_CONTROL - 0x2050
>
> dword offset 0x1c in the context image
power context, not logical context
> > - [BDW, CHV] FF_THREAD_MODE - 0x20a0
>
> dword offset 0x2a in the context image
Also power context
> > - [CHV] RC_SLEEP_PSMI_CONTROL - 0x12050
>
> Kinda surprised this one isn't there. I'm not sure how it can work correctly.
We're not frobbing with this anywhere but gen6_bsd_ring_write_tail(). In any
case it's a VCS register. Sadly I've not found any documentation for !RCS
power context, but I'm assuming every engine has a power context of some sort.
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Nov 20, 2014 at 09:59:00AM -0800, Ian Romanick wrote:
> On 08/06/2014 11:56 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Check that the target is GL_TEXTURE_CUBE_MAP before emitting
> > TEXCOORDTYPE_VECTOR texture coordinates.
&
On Wed, Aug 06, 2014 at 09:56:30PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I had a few rainy days during my summer vacation so I decided to fix a
> chromnium-bsu texturing problem that was nagging me for a while now. I
> ended up fixing a few other th
On Thu, Oct 23, 2014 at 11:19:04PM -0700, Matt Turner wrote:
> On Thu, Oct 23, 2014 at 11:01 PM, Ville Syrjälä wrote:
> > On Thu, Oct 23, 2014 at 04:44:03PM -0700, Matt Turner wrote:
> >> ---
> >> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
>
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
> I know this isn't exactly what your patch looked to support, but
> shouldn't MESA_FORMAT_L16A16_UNORM be tried as a lossless alternative
> also?
I suppose, but I suspect you'll have a hard time finding hardware that
supports L16A16 but not A16.
--
Ville Syrjälä
Intel OTC
__
Sorry, ignore these. Shell history and fast fingers are a dangerous
combination...
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Aug 06, 2014 at 01:44:45PM -0700, Eric Anholt wrote:
> ville.syrj...@linux.intel.com writes:
>
> > From: Ville Syrjälä
> >
> > Gen2 doesn't have fragmnts shaders so we shouldn't be calling
>
> spelling^
Fixed locally.
>
> Othe
j...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Fix an off by one in the texture unit walk during texblend
> > setup on gen2. This caused the last enabled texunit to be
> > skipped resulting in totally messed up texturing.
&g
Author: Brian
> >Date: Fri Jul 6 16:51:19 2007 -0600
> >
> > In _swsetup_Translate(), update dest->attrib[FRAG_ATTRIB_COL0].]
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27499
> > Cc: Brian Paul
> > Signed-off-by: Ville Syrjälä
whomever else cares. If
> people are happy to drop that idea on the floor I won't shed a single
> tear.
I broke that idea alredy when I cooked up the current drm fourccs.
I didn't cross check them with any other fourcc source, so I'm 100%
sure most of them don't match any
On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
> Ville Syrjälä writes:
>
> > What is this format anyway? -ENODOCS
>
> Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
>
> > If its just an srgb version of ARGB, then I wouldn't re
is format anyway? -ENODOCS
If its just an srgb version of ARGB, then I wouldn't really want it
in drm_fourcc.h. I expect colorspacy stuff will be handled by various
crtc/plane properties in the kernel so we don't need to encode that
stuff into the fb format.
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
ve that
> already, just haven't noticed yet :(
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
dvertise OpenGL 2.1 support for gen3 hardware. So maybe
Mesa 9.2ish or so?
I think your hardware is a pineview (can't really check w/o the pci id
though), and that should be gen3 AFAIK.
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
still interested.
>From 47f51b19137603dccaa4fcb2a703d56335c292fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?=
Date: Wed, 14 Aug 2013 15:12:29 +0300
Subject: [PATCH] make bos uncached in PTEs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transf
On Thu, Aug 15, 2013 at 08:08:12AM -0700, Chad Versace wrote:
> On 08/14/2013 12:50 AM, Ville Syrjälä wrote:
> > On Wed, Aug 14, 2013 at 10:45:23AM +0300, Ville Syrjälä wrote:
> >> On Tue, Aug 13, 2013 at 05:46:55PM -0700, Chad Versace wrote:
> >>> On 08/13/201
On Wed, Aug 14, 2013 at 10:45:23AM +0300, Ville Syrjälä wrote:
> On Tue, Aug 13, 2013 at 05:46:55PM -0700, Chad Versace wrote:
> > On 08/13/2013 03:31 PM, Vedran Rodic wrote:
> > > On Mon, Aug 12, 2013 at 3:07 PM, wrote:
> > >> From: Ville Syrjälä
> > &g
On Tue, Aug 13, 2013 at 05:46:55PM -0700, Chad Versace wrote:
> On 08/13/2013 03:31 PM, Vedran Rodic wrote:
> > On Mon, Aug 12, 2013 at 3:07 PM, wrote:
> >> From: Ville Syrjälä
> >>
> >> IVB/BYT also has the same L3 cacheability control in MOCS
ther.
But it's been quite a while since I poked at any dri2 or composite stuff
so I may be out of practice.
[1] http://patchwork.freedesktop.org/patch/12111/
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
f the lastStamp before
doing GetBuffers, and retry if the snapshot and the current
lastStamp no longer match after the GetBuffers reply has been
processed.
Signed-off-by: Ville Syrjälä
---
Sigh. So no one actually took the bait based on the original
patch submission (apart from a small nibble from Dave).
On Fri, Jan 13, 2012 at 09:10:15AM +, Dave Airlie wrote:
> On Sun, Dec 18, 2011 at 4:22 PM, Ville Syrjälä wrote:
> > Ever since xserver commit 531869448d07e00ae241120b59f35709d59c,
> > the server no longer sends invalidate events to clients, unless they
> > have p
On Fri, Jan 13, 2012 at 09:10:15AM +, Dave Airlie wrote:
> On Sun, Dec 18, 2011 at 4:22 PM, Ville Syrjälä wrote:
> > Ever since xserver commit 531869448d07e00ae241120b59f35709d59c,
> > the server no longer sends invalidate events to clients, unless they
> > have p
PING PING PING! No one cares about Mesa 7.11 anymore?
On Sat, Jan 07, 2012 at 12:12:24AM +0200, Ville Syrjälä wrote:
> On Sun, Dec 18, 2011 at 06:22:01PM +0200, Ville Syrjälä wrote:
> > Ever since xserver commit 531869448d07e00ae241120b59f35709d59c,
> > the server no longer s
On Sun, Dec 18, 2011 at 06:22:01PM +0200, Ville Syrjälä wrote:
> Ever since xserver commit 531869448d07e00ae241120b59f35709d59c,
> the server no longer sends invalidate events to clients, unless they
> have performed a GetBuffers request since the drawable was last
> invalidated.
ffers, and retry if the snapshot and the current
lastStamp no longer match after the GetBuffers reply has been
processed.
Signed-off-by: Ville Syrjälä
---
It looks like master should already handle this, as there's a
retry loop inside st_framebuffer_validate(). I didn't test that
in
On Sun, Sep 26, 2010 at 10:08:43AM -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ville Syrjälä wrote:
> > On Fri, Sep 24, 2010 at 05:08:49PM -0700, Eric Anholt wrote:
> >> This drops the screen-depth-dependent texture formatting an
; + if (MGA_IS_G400(mmesa)) {
> + ctx->texture_format_supported[MESA_FORMAT_I8] = GL_TRUE;
> + ctx->texture_format_supported[MESA_FORMAT_AL88] = GL_TRUE;
> +
> + /* ctx->Extensions.MESA_ycbcr_texture */
> + ctx->texture_format_supported[MESA_FORMAT_YCBCR
81 matches
Mail list logo
