Re: [Mesa-dev] [PATCH 1/8] st/mesa: implement "zombie" sampler views

On Fri, Mar 15, 2019 at 8:55 AM Jose Fonseca wrote: > > On 14/03/2019 19:37, Brian Paul wrote: > > When st_texture_release_all_sampler_views() is called the texture may > > have sampler views belonging to several contexts. If we unreference a > > sampler view and its refcount hits zero, we need

Re: [Mesa-dev] Thoughts on fp64 for GLES?

On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier wrote: > > > > On Wednesday, 13 February 2019, Stéphane Marchesin > wrote: >> >> On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier >> wrote: >> > >> > >> > >> > On Wednesday, 1

Re: [Mesa-dev] Thoughts on fp64 for GLES?

On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier wrote: > > > > On Wednesday, 13 February 2019, Ilia Mirkin wrote: >> >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier >> wrote: >> > >> > On Fri, Jan 25, 2019 at 11:52:56AM -0800, Stéphane Marches

Re: [Mesa-dev] Thoughts on fp64 for GLES?

On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny wrote: > > Am Donnerstag, den 24.01.2019, 22:25 -0800 schrieb Stéphane Marchesin: > > > > Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on > > the guest side, we need fp64 on the host... > > BTW: we c

Re: [Mesa-dev] Thoughts on fp64 for GLES?

On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote: > > Hi; > > On 1/25/19 4:57 AM, Stéphane Marchesin wrote: > > Hi, > > > > We'd like to expose fp64 functionality on Chrome OS where we only have > > GLES. It seems like a simple approach is to enable th

[Mesa-dev] Thoughts on fp64 for GLES?

Hi, We'd like to expose fp64 functionality on Chrome OS where we only have GLES. It seems like a simple approach is to enable this extension for GLES: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt Anyone knows if what's the right thing to do? It seems to me that

Re: [Mesa-dev] Chromium - Application-level nouveau blacklist

On Tue, Jan 8, 2019 at 1:11 AM Eero Tamminen wrote: > > Hi, > > On 8.1.2019 8.56, Stéphane Marchesin wrote: > > Yes I think the Chrome-side is very simple here: because there isn't > > time or means for in-depth investigation, if a driver crashes too > > much, it g

Re: [Mesa-dev] Chromium - Application-level nouveau blacklist

On Sat, Jan 5, 2019 at 11:37 PM Jason Ekstrand wrote: > > On Sat, Jan 5, 2019 at 2:40 PM Ilia Mirkin wrote: >> >> It looks like as of Chromium 71, nouveau is completely blacklisted. > > > That's rather unfortunate. :-( The intel mesa drivers were also blacklisted > for quite some time a while

[Mesa-dev] [PATCH] virgl: Implement seamless cube maps

This was previously ignored. Along with the virglrenderer patch, this fixes ~100 dEQP tests: dEQP-GLES3.functional.texture.filtering.cube.* Signed-off-by: Stéphane Marchesin <marc...@chromium.org> --- src/gallium/drivers/virgl/virgl_encode.c | 3 ++- src/gallium/drivers/virgl/virgl_prot

Re: [Mesa-dev] [PATCH 2/2] virgl: reduce some default capset limits.

; > Signed-off-by: Dave Airlie <airl...@redhat.com> Reviewed-by: Stéphane Marchesin <marc...@chromium.org> > --- > src/gallium/drivers/virgl/virgl_winsys.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/src/gallium/drivers/virgl/

Re: [Mesa-dev] [PATCH 1/2] virgl: handle getting new capsets.

<airl...@redhat.com> Reviewed-by: Stéphane Marchesin <marc...@chromium.org> > --- > src/gallium/drivers/virgl/virgl_winsys.h | 25 ++- > src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 52 > ++ > src/gallium/winsys/virgl/drm/vir

[Mesa-dev] [PATCH] virgl: Support v2 caps struct

This struct allows us to report accurate max point size/line width. --- src/gallium/drivers/virgl/virgl_hw.h| 29 + src/gallium/drivers/virgl/virgl_screen.c| 9 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 19 +++- 3 files

Re: [Mesa-dev] XDC 2017 : Call for paper

t to make badges and plan for the catering, so if you are > attending please add your name as early as possible. > > I am looking forward to seeing you there. If you have any > inquiries/questions, please send them to Stéphane Marchesin (please also > CC: board at foundation.x.org). Hi

Re: [Mesa-dev] [PATCH] renderonly: use drmIoctl

On Fri, Apr 28, 2017 at 6:06 AM, Emil Velikov wrote: > On 28 April 2017 at 13:55, Eric Engestrom > wrote: > > On Friday, 2017-04-28 13:14:20 +0200, Philipp Zabel wrote: > >> To restart interrupted system calls, use drmIoctl. > >> > >>

Re: [Mesa-dev] [PATCH] Revert "i915: Always enable GL 2.0 support."

On Sun, Jan 29, 2017 at 8:29 PM, Kenneth Graunke wrote: > On Sunday, January 29, 2017 6:20:10 PM PST Matt Turner wrote: >> This partially reverts commit 97217a40f97cdeae0304798b607f704deb0c3558. >> It leaves ES 2.0 support in place per Ian's suggestion, because ES 2.0 >> is

Re: [Mesa-dev] [PATCH] i915g: fix incorrect gl_FragCoord value

I pushed it. Thanks Nicholas. Stéphane On Thu, Sep 22, 2016 at 9:40 AM, Roland Scheidegger wrote: > Am 22.09.2016 um 17:40 schrieb Emil Velikov: > > Hi Nicholas, > > > > On 26 August 2016 at 00:31, Nicholas Bishop > wrote: > >> From: Nicholas Bishop

Re: [Mesa-dev] [PATCH] i915g: fix incorrect gl_FragCoord value

On Thu, Sep 22, 2016 at 8:40 AM, Emil Velikov wrote: > Hi Nicholas, > > On 26 August 2016 at 00:31, Nicholas Bishop wrote: > > From: Nicholas Bishop > > > > On Intel Pineview M hardware, the i915 gallium driver doesn't

Re: [Mesa-dev] [PATCH 07/10] egl/android: Make drm_gralloc headers optional

On Tue, Jul 19, 2016 at 6:36 AM, Rob Clark wrote: > On Tue, Jul 19, 2016 at 6:54 AM, Emil Velikov > wrote: >> On 19 July 2016 at 04:21, Tomasz Figa wrote: >>> On Tue, Jul 19, 2016 at 2:35 AM, Emil Velikov

Re: [Mesa-dev] [PATCH] Make single-buffered GLES representation internally consistent

celess platform with no regressions. > > v2: Corrected unclear comment > v3: Make the change in context.c instead of get.c > v4: Removed whitespace I looked for a better way than initializing from makecurrent, but there doesn't seem to be one, so... Reviewed-by: <Stéphane Marchesin marc.

Re: [Mesa-dev] [PATCH] Integrate precise trig into configuration infrastructure

On Wed, May 11, 2016 at 1:32 PM, Gurchetan Singh <gurchetansi...@chromium.org> wrote: > With this change, to enable precise SIN and COS instructions > on Intel hardware, one can put > > > > in the proper drirc file. > > V2: Make option name more generic Reviewe

Re: [Mesa-dev] GBM YUV planar support

On Thu, Jun 2, 2016 at 2:41 PM, Kristian Høgsberg wrote: > On Thu, Jun 2, 2016 at 11:52 AM, Rob Herring wrote: >> On Thu, Jun 2, 2016 at 1:31 PM, Rob Clark wrote: >>> On Thu, Jun 2, 2016 at 1:51 PM, Rob Herring wrote:

Re: [Mesa-dev] [PATCH] Added pbuffer hooks for surfaceless platform

On Fri, May 6, 2016 at 3:32 PM, Gurchetan Singh <gurchetansi...@chromium.org> wrote: > This change enables the creation of pbuffer > surfaces on the surfaceless platform. > > V2: Use double-buffered pbuffer configuration Reviewed-by: Stéphane Marchesin <marc...@chromium.or

Re: [Mesa-dev] [PATCH 7/8] glx: fix the refcounting of dri drawables

On Thu, Apr 7, 2016 at 10:44 AM, Miklós Máté <mtm...@gmail.com> wrote: > On 04/07/2016 12:40 PM, Stéphane Marchesin wrote: >> >> On Thu, Apr 7, 2016 at 3:37 AM, Miklós Máté <mtm...@gmail.com> wrote: >>> >>> On 04/07/2016 12:25 PM, Stéphane Marchesin wro

Re: [Mesa-dev] [PATCH 7/8] glx: fix the refcounting of dri drawables

On Thu, Apr 7, 2016 at 3:37 AM, Miklós Máté <mtm...@gmail.com> wrote: > On 04/07/2016 12:25 PM, Stéphane Marchesin wrote: > > > On Apr 7, 2016 02:27, "Michel Dänzer" <mic...@daenzer.net> wrote: >> >> On 07.04.2016 18:01, Marek Olšák wrote: >&g

Re: [Mesa-dev] [PATCH 7/8] glx: fix the refcounting of dri drawables

On Apr 7, 2016 02:27, "Michel Dänzer" wrote: > > On 07.04.2016 18:01, Marek Olšák wrote: > > On Thu, Apr 7, 2016 at 7:32 AM, Ian Romanick wrote: > >> Why would you do that? I've NAKed this patch several times. > > > > You NAKed the previous version of

Re: [Mesa-dev] [PATCH 7/8] glx: fix the refcounting of dri drawables

On Mar 23, 2016 17:13, "Miklós Máté" wrote: > > This fixes premature deallocation on unbind, and introduces > support for deleting GLX drawables while they are current to a context. > > Note that in practice this also introduces a resource leak, because nobody > uses the GLX 1.3

Re: [Mesa-dev] [android-x86-devel] Re: gralloc_drm_pipe

On Mar 26, 2016 16:05, "Rob Clark" <robdcl...@gmail.com> wrote: > > On Sat, Mar 26, 2016 at 6:42 PM, Stéphane Marchesin > <stephane.marche...@gmail.com> wrote: > > > > On Mar 26, 2016 3:09 PM, "Rob Clark" <robdcl...@gmail.com> wrote: &g

Re: [Mesa-dev] [android-x86-devel] Re: gralloc_drm_pipe

On Mar 26, 2016 3:09 PM, "Rob Clark" <robdcl...@gmail.com> wrote: > > On Fri, Mar 25, 2016 at 9:38 PM, Stéphane Marchesin <marc...@google.com> wrote: > > On Wed, Mar 23, 2016 at 5:22 PM, Rob Herring <r...@kernel.org> wrote: > >> On Fri, Mar 4,

Re: [Mesa-dev] [android-x86-devel] Re: gralloc_drm_pipe

On Wed, Mar 23, 2016 at 5:22 PM, Rob Herring wrote: > On Fri, Mar 4, 2016 at 12:07 PM, Rob Clark wrote: >> On Fri, Mar 4, 2016 at 12:59 PM, Rob Clark wrote: >>> So, I've been advocating that for android, gallium drivers use >>>

Re: [Mesa-dev] [PATCH] gallium/swr: update rasterizer (532172)

On Tue, Mar 22, 2016 at 8:55 PM, Rowley, Timothy O wrote: > >> On Mar 22, 2016, at 3:51 PM, Justen, Jordan L >> wrote: >> >> What does 532172 in the subject refer to? > > swr rasterizer development happens in another source control system.

Re: [Mesa-dev] [PATCH 1/3] llvmpipe: use vector loads for (optimized) tri raster funcs

On Mon, Feb 1, 2016 at 8:14 AM, Brian Paul wrote: > On 01/31/2016 06:00 PM, srol...@vmware.com wrote: >> >> From: Roland Scheidegger >> >> When we switched to 64bit rasterization, we could no longer use straight >> aligned loads for loading the plane data.

Re: [Mesa-dev] Using the right context in st_texture_release_all_sampler_views()

On Thu, Jul 23, 2015 at 9:55 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jul 22, 2015 at 6:32 PM, Brian Paul bri...@vmware.com wrote: Hi Marek, This is regarding your commit st/mesa: use pipe_sampler_view_release for releasing sampler views from last October. Basically, we have:

Re: [Mesa-dev] [PATCH 1/2] egl/dri2: implement platform_null (v2).

On Fri, Apr 3, 2015 at 1:35 PM, Chad Versace chad.vers...@intel.com wrote: Time to revive this patch! Why? - I don't like large patchsets living in Chrome OS for too long. - Frank submitted Waffle patches to support this, and I hesitate to add Waffle support unless the platform is

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On Wed, Aug 20, 2014 at 11:56 AM, Matt Turner matts...@gmail.com wrote: On Wed, Aug 20, 2014 at 11:13 AM, Kenneth Graunke kenn...@whitecape.org wrote: Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more. Yes, at one

Re: [Mesa-dev] Broadcom VC4 project

On Wed, Jun 18, 2014 at 10:47 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 18/06/14 08:28, Eric Anholt wrote: To those who have been curious what I was up to: I wasn't sure when I could announce my new projecct, I just got the ack day before yesterday, and I've been a little busy. I'm

Re: [Mesa-dev] [PATCH v3 1/2] Import eglextchromium.h from Chromium.

...@linux.intel.com Reviewed-by: Chad Versace chad.vers...@linux.intel.com Cc: Jamey Sharp ja...@minilop.net Cc: Ian Romanick i...@freedesktop.org Cc: Stéphane Marchesin stephane.marche...@gmail.com --- v3: Add an include guard on Chromium header. include/EGL/eglext.h | 1 + include/EGL

Re: [Mesa-dev] [PATCH] egl: Add GetSyncValuesCHROMIUM extension.

On Tue, Apr 22, 2014 at 12:19 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Sat, Apr 19, 2014 at 12:34:37PM -0700, Stéphane Marchesin wrote: On Fri, Apr 18, 2014 at 3:37 PM, Sarah Sharp sarah.a.sh...@linux.intel.comwrote: Chromium defined a new GL extension (that isn't

Re: [Mesa-dev] [PATCH] egl: Add GetSyncValuesCHROMIUM extension.

On Fri, Apr 18, 2014 at 3:37 PM, Sarah Sharp sarah.a.sh...@linux.intel.comwrote: Chromium defined a new GL extension (that isn't registered with Khronos). This here is the problem IMO. I'll see next week what we can do about pushing for this to become a registered extension. Intel would be our

Re: [Mesa-dev] [PATCH 19/25] gallium/i915: handle query_renderer caps

On Sat, Feb 22, 2014 at 5:22 AM, Emil Velikov emil.l.veli...@gmail.comwrote: On 22/02/14 03:33, Stéphane Marchesin wrote: On Fri, Feb 21, 2014 at 7:04 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Implementation is a verbatim copy from the classic driver. This introduces a driver

Re: [Mesa-dev] [PATCH 19/25] gallium/i915: handle query_renderer caps

On Fri, Feb 21, 2014 at 7:04 PM, Emil Velikov emil.l.veli...@gmail.comwrote: Implementation is a verbatim copy from the classic driver. This introduces a driver dependency on libdrm-intel, as the winsys does not cache the aperture size of the device. Usually if you have to add calls into

Re: [Mesa-dev] [PATCH] loader: Make drmGetVersion logic conditional on non-pci devices

On Thu, Jan 30, 2014 at 12:07 AM, Eric Anholt e...@anholt.net wrote: Stéphane Marchesin marc...@chromium.org writes: On systems without libudev, the loader_get_pci_id_for_fd() call will return 0, which will trigger the drmGetVersion logic. Sadly, this logic assumes that the kernel driver

Re: [Mesa-dev] [PATCH] loader: Make drmGetVersion logic conditional on non-pci devices

On Thu, Jan 30, 2014 at 12:20 AM, Stéphane Marchesin stephane.marche...@gmail.com wrote: On Thu, Jan 30, 2014 at 12:07 AM, Eric Anholt e...@anholt.net wrote: Stéphane Marchesin marc...@chromium.org writes: On systems without libudev, the loader_get_pci_id_for_fd() call will return 0

Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?

On Fri, Jan 24, 2014 at 4:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: Hi, I am investigating what kind of Wayland protocol extensions would be needed to support proper presentation timing. Looking at existing works, I am wondering about two things whether they have any real use. Where

Re: [Mesa-dev] [PATCH 4/7] dri2: Trust our own driver name lookup over the server's.

On Tue, Jan 28, 2014 at 2:13 PM, Ian Romanick i...@freedesktop.org wrote: On 01/28/2014 02:51 PM, Mark Mueller wrote: This patch could cause the i965 driver to not load if Mesa was built on a system without libudev devel present. For example on Fedora one should install systemd-devel

[Mesa-dev] [PATCH] loader: Make drmGetVersion logic conditional on non-pci devices

On systems without libudev, the loader_get_pci_id_for_fd() call will return 0, which will trigger the drmGetVersion logic. Sadly, this logic assumes that the kernel driver name matches the dri driver name, which is not the case on recent intel GPUs (for example i965 dri driver and i915 kernel

Re: [Mesa-dev] [PATCH] i965/gen6: Fix HiZ hang in WebGL Google maps

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70740 Signed-off-byhttps://bugs.freedesktop.org/show_bug.cgi?id=70740Signed-off-by: Stéphane Marchesin marc...@chromium.org Signed-off-by: Chad Versace chad.vers...@linux.intel.com --- src/mesa/drivers/dri/i965/gen6_blorp.cpp | 12

Re: [Mesa-dev] [PATCH V2 05/17] i915: Modified i915_buffer_create to use memory allocation alignment of 64 instead of 16.

5 and 6 look good. One nitpick, please prefix the i915g changes with i915g instead of i915 so it's obvious which driver is being changed from just looking at a git log. Stéphane On Thu, Nov 28, 2013 at 12:56 AM, Siavash Eliasi siavashser...@gmail.com wrote: ---

Re: [Mesa-dev] [PATCH 15/18] docs: Import extension spec for GLX_MESA_query_renderer

On Thu, Nov 7, 2013 at 1:22 PM, Dave Airlie airl...@gmail.com wrote: On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com The enumerated values are currently allocated from Intel's range. Some highlevel comments below,

Re: [Mesa-dev] Dropping the xorg state tracker

On Wed, Nov 6, 2013 at 5:43 PM, Matt Turner matts...@gmail.com wrote: With the removal of the r600 and radeonsi xorg targets, the only ones left are i915 and nouveau. Does anyone have a compelling reason to keep them (and the state tracker code itself) around anymore? I'm fine with removing

Re: [Mesa-dev] [PATCH 1/3] draw: cleanup the extra attribs

On Tue, Sep 3, 2013 at 9:38 PM, Matt Turner matts...@gmail.com wrote: On Tue, Sep 3, 2013 at 8:20 PM, Stéphane Marchesin stephane.marche...@gmail.com wrote: Hi Zack, This change regresses a bunch of point sprite piglit tests on i915g. Should we revert back to the old behaviour? As far

[Mesa-dev] [PATCH] Revert draw: cleanup the extra attribs

This reverts commit 57cd3267782fcf92d1e7d772760956516d4367df. This fixes piglit regressions with additional draw stages on llvmpipe, softpipe and i915g. The attributes can't be cleared at this point because they might be in use by the additional draw stages.

Re: [Mesa-dev] [PATCH 1/3] draw: cleanup the extra attribs

On Wed, Sep 4, 2013 at 12:46 PM, Zack Rusin za...@vmware.com wrote: Hi, Stéphane. No we should not revert to the old behavior. The old behavior was incorrect. Consider this: -- setup state that draws a wireframe - draw should inject frontface -- the driver needs to be able to find the

Re: [Mesa-dev] [PATCH 1/3] draw: cleanup the extra attribs

On Wed, Sep 4, 2013 at 2:33 PM, Stéphane Marchesin stephane.marche...@gmail.com wrote: On Wed, Sep 4, 2013 at 12:46 PM, Zack Rusin za...@vmware.com wrote: Hi, Stéphane. No we should not revert to the old behavior. The old behavior was incorrect. Consider this: -- setup state

Re: [Mesa-dev] [PATCH 1/3] draw: cleanup the extra attribs

Hi Zack, This change regresses a bunch of point sprite piglit tests on i915g. Should we revert back to the old behaviour? As far as I can see, it was correct (it was keeping the attributes in case another stage is using them). Stéphane On Thu, Aug 8, 2013 at 12:46 PM, Zack Rusin

Re: [Mesa-dev] [Patch] Sharing flags should disable tiling

On Mon, Aug 12, 2013 at 2:29 PM, Ian Romanick i...@freedesktop.org wrote: On 08/11/2013 03:50 AM, davya...@free.fr wrote: This looks good to me, but commit messages should have a prefix indicating which component is changed. In your case it's gallium: and intel:, respectively. Marek Ok,

Re: [Mesa-dev] [Patch] Sharing flags should disable tiling

On Mon, Aug 12, 2013 at 3:05 PM, Marek Olšák mar...@gmail.com wrote: On Mon, Aug 12, 2013 at 11:36 PM, Stéphane Marchesin stephane.marche...@gmail.com wrote: Other than hybrid systems (of which there are none with i915 graphics), is there any case where __DRI_IMAGE_USE_SHARE can occur? You

Re: [Mesa-dev] [PATCH 3/4] mesa: Track the TexImage being rendered to in the gl_renderbuffer.

On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 07/09/2013 04:33 PM, Stéphane Marchesin wrote: On Fri, May 10, 2013 at 11:37 PM, Eric Anholt e...@anholt.net wrote: We keep having to pass the attachments around with our gl_renderbuffers because that's the only

Re: [Mesa-dev] [PATCH 3/4] mesa: Track the TexImage being rendered to in the gl_renderbuffer.

On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie airl...@gmail.com wrote: On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin stephane.marche...@gmail.com wrote: On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 07/09/2013 04:33 PM, Stéphane Marchesin wrote

Re: [Mesa-dev] [PATCH] st/dri/sw: Fix pitch calculation in drisw_update_tex_buffer

that: Reviewed-by: Stéphane Marchesin marc...@chromium.org + ximage_stride = ((w * cpp) + 3) -4; for (line = h-1; line; --line) { memmove(map[line * transfer-stride], map[line * ximage_stride], -- 1.7.11.7 ___ mesa-dev mailing

Re: [Mesa-dev] [PATCH] Fixed bug in unclamped float to ubyte conversion.

is the IEEE float representation of 1.0f. 0x3f7f7f81 (or any value in between) would also work, but 1.0f is probably cleaner. The patch does not regress piglit on llvmpipe and on i965 on sandy bridge. Tested-by Stéphane Marchesin marc...@chromium.org Reviewed-by Stéphane Marchesin marc...@chromium.org

Re: [Mesa-dev] [PATCH 1/2] st/xlib: Fix upside down coordinates for CopySubBuffer

Anyone wants to look at those 2? I realize it's not a super common combination (copysubbuffers + client-side glx) but still :) Stéphane On Sat, May 11, 2013 at 1:38 PM, Stéphane Marchesin marc...@chromium.org wrote: The coordinates need to be inverted between glX and gallium. --- src

[Mesa-dev] [PATCH 1/2] st/xlib: Fix upside down coordinates for CopySubBuffer

The coordinates need to be inverted between glX and gallium. --- src/gallium/state_trackers/glx/xlib/xm_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c b/src/gallium/state_trackers/glx/xlib/xm_api.c index e426192..4f10b84

[Mesa-dev] [PATCH 2/2] st/xlib: Flush the front buffer before doing CopySubBuffer

We flush pending rendering before running CopySubBuffer, which ensures that the right bits get to the screen. --- src/gallium/state_trackers/glx/xlib/xm_api.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c

Re: [Mesa-dev] [PATCH] Fixed bug in unclamped float to ubyte conversion.

in between) would also work, but 1.0f is probably cleaner. The patch does not regress piglit on llvmpipe and on i965 on sandy bridge. Tested-by Stéphane Marchesin marc...@chromium.org Reviewed-by Stéphane Marchesin marc...@chromium.org --- src/gallium/auxiliary/util/u_math.h | 4 ++-- src

[Mesa-dev] [PATCH] draw/llvm: Add additional llvm optimization passes

It helps a bit with vertex shader performance on i915g (a couple percent faster with openarena). I have tried most other passes, and they weren't showing any measurable improvement. Note that my vertex shaders didn't have loops, so maybe the loop optimizations could still be useful in the future.

Re: [Mesa-dev] Mesa (master): Don't bother making compatibilty symlinks

Jon, It looks like this commit (and the other ones in the series) aren't present in the mesa git tree. It also looks like the last commit was pushed twice, and is present with the hash from the second time. Stéphane On Tue, Mar 5, 2013 at 5:26 AM, Jon TURNEY jtur...@kemper.freedesktop.org

Re: [Mesa-dev] [PATCH] st/mesa: bound the sampler count before calling into the driver.

On Sat, Mar 9, 2013 at 1:35 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote: Looks a sensible thing to do. Reviewed-by: Jose Fonseca jfons...@vmware.com Thanks for the review. Any

Re: [Mesa-dev] [PATCH] st/mesa: bound the sampler count before calling into the driver.

On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote: Looks a sensible thing to do. Reviewed-by: Jose Fonseca jfons...@vmware.com Thanks for the review. Any insight how the caller can be fixed so that this doesn't happen? It happens to me when draw stages add more

[Mesa-dev] [PATCH] st/mesa: bound the sampler count before calling into the driver.

With the current code, the sampler count can become higher than PIPE_MAX_SAMPLERS and once it gets to the driver this can lead to miscellaneous crashes and memory corruptions. Although this is taken care of in debug mode with an assert, there is still a way to cause a crash/overflow in release

Re: [Mesa-dev] [PATCH v2 2/2] configure.ac: Build dricommon when dri is enabled

to do so, the HAVE_*_DRI conditionals must be moved after the last assignment of HAVE_COMMON_DRI. Tested-by: Stéphane Marchesin marc...@chromium.org --- configure.ac | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index

[Mesa-dev] [PATCH] glx: Check that swap_buffers_reply is non-NULL before using it

Check that the return value from xcb_dri2_swap_buffers_reply is non-NULL before accessing the struct members. --- src/glx/dri2_glx.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c index a51716f..78a2a42 100644 ---

Re: [Mesa-dev] [PATCH] mesa: add bounds checking for uniform array access

for the location of a non-existent array element, as it should. Signed-off-by: Frank Henigman fjhenig...@google.com Reviewed-by: Stéphane Marchesin marc...@chromium.org --- src/mesa/main/uniform_query.cpp | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff

Re: [Mesa-dev] new i965g pipe driver for Intel GEN6 (and later)

On Wed, Dec 12, 2012 at 3:49 PM, Roland Scheidegger srol...@vmware.com wrote: This is interesting, personally I'm fine with getting this merged. That said, there was a i965g driver upstream before (though it never worked right IIRC and was probably gen4 or maybe gen5 too only due to its age),

Re: [Mesa-dev] [PATCH v2 3/6] glapi: Alias VertexAttribDivisor and VertexAttribDivisorARB.

On Thu, Oct 25, 2012 at 8:10 AM, Paul Berry stereotype...@gmail.com wrote: On 24 October 2012 12:01, Stéphane Marchesin stephane.marche...@gmail.com wrote: Hi Paul, This change regresses instanced_arrays with i915g, and probably with llvmpipe as well. Could you take a look? Thanks

Re: [Mesa-dev] [PATCH v2 3/6] glapi: Alias VertexAttribDivisor and VertexAttribDivisorARB.

Hi Paul, This change regresses instanced_arrays with i915g, and probably with llvmpipe as well. Could you take a look? Thanks, Stéphane On Mon, Oct 22, 2012 at 5:22 PM, Paul Berry stereotype...@gmail.com wrote: There's no reason to have separate slots in the dispatch table for these two

Re: [Mesa-dev] [PATCH] gallium: unify transfer functions

On Tue, Oct 9, 2012 at 6:04 PM, Marek Olšák mar...@gmail.com wrote: Hi, this is actually a very small cleanup that got unexpectedly big. I really underestimated the size of gallium. It's part of the plan discussed here:

Re: [Mesa-dev] wider registers in llvmpipe

On Sun, Oct 7, 2012 at 3:37 PM, Stéphane Marchesin stephane.marche...@gmail.com wrote: On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - Am 18.07.2012 07:11, schrieb Marek Olšák: On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegger srol

Re: [Mesa-dev] wider registers in llvmpipe

On Mon, Oct 8, 2012 at 6:25 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Sun, Oct 7, 2012 at 3:37 PM, Stéphane Marchesin stephane.marche...@gmail.com wrote: On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca jfons...@vmware.com wrote: [...] I can't reproduce

Re: [Mesa-dev] wider registers in llvmpipe

On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - Am 18.07.2012 07:11, schrieb Marek Olšák: On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegger srol...@vmware.com wrote: Am 17.07.2012 23:49, schrieb Stéphane Marchesin: On Mon, Jul 16

Re: [Mesa-dev] Mesa (master): configure.ac: Don't duplicate CFLAGS

Hi Matt, This patch breaks the build for me on one of my machines (Fedora 15): gmake[3]: Entering directory `/home/marcheu/mesa/src/glsl/glcpp' LEXglcpp-lex.c YACC glcpp-parse.c CXXglsl_lexer.lo updating glcpp-parse.h updating glcpp-parse.output gmake all-am gmake[4]: Entering

Re: [Mesa-dev] Gallium: Moving BlitFramebuffer implementation into drivers

On Sat, Sep 8, 2012 at 2:52 PM, Marek Olšák mar...@gmail.com wrote: Hi everyone, I'd like to move the BlitFramebuffer implementation into gallium drivers. The pros are: - allowing MSAA resource blitting to be accelerated on any hardware - allowing stencil blitting to be accelerated on any

Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x

On Fri, Sep 7, 2012 at 8:19 AM, Matt Turner matts...@gmail.com wrote: On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca jfons...@vmware.com wrote: Matt, I see you went ahead and just disabled

[Mesa-dev] [PATCH 1/2] intel: Prevent huge lastlevel values from being computed.

The current computation for the lastlevel is based on the level size and can lead to writing past the end of the texture array. Instead we clamp it by MAX_TEXTURE_LEVELS. --- src/mesa/drivers/dri/intel/intel_tex_image.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git

[Mesa-dev] [PATCH 2/2] st/mesa: Prevent huge lastlevel values from being computed.

The current computation for the lastlevel is based on the level size and can lead to writing past the end of the texture array. Instead we clamp according to hardware limits. --- src/mesa/state_tracker/st_cb_texture.c | 28 +++- 1 files changed, 27 insertions(+), 1

Re: [Mesa-dev] [PATCH 1/2] intel: Prevent huge lastlevel values from being computed.

On Tue, Sep 4, 2012 at 2:59 PM, Eric Anholt e...@anholt.net wrote: Stéphane Marchesin marc...@chromium.org writes: The current computation for the lastlevel is based on the level size and can lead to writing past the end of the texture array. Instead we clamp it by MAX_TEXTURE_LEVELS

Re: [Mesa-dev] [PATCH 2/2] st/mesa: Prevent huge lastlevel values from being computed.

On Tue, Sep 4, 2012 at 3:08 PM, Brian Paul bri...@vmware.com wrote: On 09/04/2012 01:15 PM, Stéphane Marchesin wrote: The current computation for the lastlevel is based on the level size and can lead to writing past the end of the texture array. Instead we clamp according to hardware limits

Re: [Mesa-dev] [PATCH 1/2] intel: Prevent huge lastlevel values from being computed.

On Tue, Sep 4, 2012 at 3:27 PM, Ian Romanick i...@freedesktop.org wrote: On 09/04/2012 03:19 PM, Stéphane Marchesin wrote: On Tue, Sep 4, 2012 at 2:59 PM, Eric Anholt e...@anholt.net wrote: Stéphane Marchesin marc...@chromium.org writes: The current computation for the lastlevel is based

Re: [Mesa-dev] [PATCH 1/2] intel: Prevent huge lastlevel values from being computed.

On Tue, Sep 4, 2012 at 4:01 PM, Brian Paul bri...@vmware.com wrote: On 09/04/2012 04:39 PM, Ian Romanick wrote: On 09/04/2012 03:32 PM, Stéphane Marchesin wrote: On Tue, Sep 4, 2012 at 3:27 PM, Ian Romanick i...@freedesktop.org wrote: On 09/04/2012 03:19 PM, Stéphane Marchesin wrote

Re: [Mesa-dev] Mesa (master): i965: Double the size of the state cache.

On Mon, Aug 27, 2012 at 8:58 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 08/27/2012 03:00 PM, Stéphane Marchesin wrote: On Mon, Aug 27, 2012 at 2:24 PM, Kenneth Graunke k...@kemper.freedesktop.org wrote: Module: Mesa Branch: master Commit: 87cdefed405da1a57a006737297d20ba0c25fa1b

Re: [Mesa-dev] [PATCH 2/3] i965: Make the param pointer arrays for the WM dynamically sized.

On Mon, Aug 27, 2012 at 2:48 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 08/27/2012 10:49 AM, Eric Anholt wrote: Saves 26.5MB of wasted memory allocation in the l4d2 demo. --- src/mesa/drivers/dri/i965/brw_context.h | 15 --- src/mesa/drivers/dri/i965/brw_fs.cpp

[Mesa-dev] [PATCH] glsl: Fix array overflow.

Otherwise we run past the end of the array and crash. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Stéphane Marchesin marc...@chromium.org --- src/glsl/link_uniforms.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/glsl/link_uniforms.cpp b/src

Re: [Mesa-dev] wider registers in llvmpipe

On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca jfons...@vmware.com wrote: FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows llvmpipe to leverage SIMD registers wider than 128bits. Unfortunately, performance-wise this doesn't change much, as llvmpipe performance is

Re: [Mesa-dev] [PATCH 2/2] mesa/st: Generates TGSI that always recognizes INSTANCEID/VERTEXID as integers.

On Fri, Jul 13, 2012 at 5:03 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Thu, Jul 12, 2012 at 08:50:13PM +0100, jfons...@vmware.com wrote: From: José Fonseca jfons...@vmware.com Tested by running piglit draw-instanced, and by forcing llvmpipe advertise no

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

On Tue, Jul 10, 2012 at 9:04 AM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca jfons...@vmware.com wrote: Yep. The interfaces are busted. Without native integers we get DCL SV[0], INSTANCEID ... ARL

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

On Fri, Jun 29, 2012 at 3:49 PM, Olivier Galibert galib...@pobox.com wrote: On Fri, Jun 29, 2012 at 03:09:23PM -0700, Stéphane Marchesin wrote: I do, but it fixes a regression, so unless you have a fix, it's the way to go. If you have a fix I'll happily test it :) Just between us, revert

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

I'll send a revert for those, is there a way to do it without reverting the rest of the series? Stéphane On Mon, Jun 25, 2012 at 11:41 AM, Stéphane Marchesin stephane.marche...@gmail.com wrote: The specific commit that seems to break it is: 46931ecf480e1d231bb6c2236d91b5390f2465ac llvmpipe

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

21:03, Stéphane Marchesin wrote: I'll send a revert for those, is there a way to do it without reverting the rest of the series? yeah, just revert the commit you want and then via 'amend' take out the parts you don't want to revert (git gui is nice for doing that) -- Ferry Huberts

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

On Fri, Jun 29, 2012 at 3:02 PM, Olivier Galibert galib...@pobox.com wrote: On Fri, Jun 29, 2012 at 12:52:06PM -0700, Stéphane Marchesin wrote: Yeah, but my question was more high level, whether the vertex id support required the previous refactor. It looks like it does though, and I don't

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

Hi Olivier, On top of the GL_SELECT regressions reported by Brian, this patch series is causing regressions on i915g for: draw-instanced draw-instanced-divisor draw-elements-instanced-base-vertex draw-elements-instanced-base-vertex-user_varrays draw-non-instanced instance-array-dereference

Re: [Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

The specific commit that seems to break it is: 46931ecf480e1d231bb6c2236d91b5390f2465ac llvmpipe: Simplify and fix system variables fetch. On Mon, Jun 25, 2012 at 10:46 AM, Stéphane Marchesin stephane.marche...@gmail.com wrote: Hi Olivier, On top of the GL_SELECT regressions reported by Brian

  1   2   >