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 t
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, 13 F
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
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:
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 enab
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 t
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,
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 b
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
---
src/gallium/drivers/virgl/virgl_encode.c | 3 ++-
src/gallium/drivers/virgl/virgl_protocol.h | 1 +
2 files
On Tue, Feb 20, 2018 at 5:49 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> Since v2 might take a while to rollout, we should reduce
> these inside some gathered minimums and then v2 can increase
> them using host values.
>
> Signed-off-by: Dave Airlie
Reviewed-b
On Tue, Feb 20, 2018 at 5:49 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This checks the kernel api is new enough and asks for the
> larger caps size since the kernel won't mess it up now.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Stéphane Marchesin
> ---
&g
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 chan
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 all,
For logistic
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.
> >>
> >> Suggested-by: Emil Velikov
> >> Signed-off-by: Philipp Zabel
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 designed to work on har
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
> >>
> >> On Intel Pineview M hardware, th
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 output
> > the correct gl_FragCoord. It seems to always have an X coord of 0
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
>>> wrote:
On 18 July 2016 at 16:38, Tomasz Figa wrote:
> On Mon, Jul 18, 2016
On Thu, Jun 30, 2016 at 3:20 PM, Gurchetan Singh
wrote:
> There are a few places in the code where clearing and reading are done on
> incorrect buffers for GLES contexts. See comments for details. This
> fixes 75 GLES3 dEQP tests on the surfaceless platform with no regressions.
>
> v2: Corrected
On Wed, May 11, 2016 at 1:32 PM, Gurchetan Singh
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
Reviewed-by: Stéphane Marchesin
> ---
>
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:
As discussed on irc yesterday, I've been looking at adding YUV planar
>>
On Fri, May 6, 2016 at 3:32 PM, Gurchetan Singh
wrote:
> This change enables the creation of pbuffer
> surfaces on the surfaceless platform.
>
> V2: Use double-buffered pbuffer configuration
Reviewed-by: Stéphane Marchesin
Chad, do you also want to take a look at it?
> ---
>
On Thu, Apr 7, 2016 at 10:44 AM, Miklós Máté 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é wrote:
>>>
>>> On 04/07/2016 12:25 PM, Stéphane Marchesin wrote:
>>>
>>>
>>>
On Thu, Apr 7, 2016 at 3:37 AM, Miklós Máté wrote:
> On 04/07/2016 12:25 PM, Stéphane Marchesin wrote:
>
>
> 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 Romani
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 the patch, not this one. I guess
> > that me
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 glXDestroyWindow a
On Mar 26, 2016 16:05, "Rob Clark" wrote:
>
> On Sat, Mar 26, 2016 at 6:42 PM, Stéphane Marchesin
> wrote:
> >
> > On Mar 26, 2016 3:09 PM, "Rob Clark" wrote:
> >>
> >> On Fri, Mar 25, 2016 at 9:38 PM, Stéphane Marchesin
> >&g
On Mar 26, 2016 3:09 PM, "Rob Clark" wrote:
>
> On Fri, Mar 25, 2016 at 9:38 PM, Stéphane Marchesin
wrote:
> > 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
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
>>> gralloc_drm_pipe, since with android it seems like you end up with
>
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. 532172
> is a revision id to checkpoint where we’ve pu
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. However, what the code actually
>> does
On Thu, Jul 23, 2015 at 9:55 AM, Alex Deucher wrote:
> On Wed, Jul 22, 2015 at 6:32 PM, Brian Paul 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:
>>
>> void
>> st_texture_
On Fri, Apr 3, 2015 at 1:35 PM, Chad Versace 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 upstream.
>
> Of cours
On Wed, Aug 20, 2014 at 11:56 AM, Matt Turner wrote:
> On Wed, Aug 20, 2014 at 11:13 AM, Kenneth Graunke
> wrote:
>> Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo
>> Mesa package mantainer) can probably comment more.
>
> Yes, at one point we were stuck two releases
On Wed, Jun 18, 2014 at 10:47 AM, Emil Velikov 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 working towar
t; 2FRftkP8qhPrxRicKdXx3XfVSc%3D%0A&s=2407723a2ca5c591b15d9b78ec2362
>>> a9a3c0d624cec2f3005cc3caed97e518d7
>>>
>>>
>>> I have imported the header file and added the license text to the top.
>>> The only change was to fix the include guard on the
On Tue, Apr 22, 2014 at 12:19 PM, Sarah Sharp 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
> > wrote:
> >
> > > Chromium defined a new GL extension (that isn't registered with
>
On Fri, Apr 18, 2014 at 3:37 PM, Sarah Sharp
wrote:
> 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 2nd
implementation, so I th
On Sat, Feb 22, 2014 at 5:22 AM, Emil Velikov wrote:
> On 22/02/14 03:33, Stéphane Marchesin wrote:
> > On Fri, Feb 21, 2014 at 7:04 PM, Emil Velikov >wrote:
> >
> >> Implementation is a verbatim copy from the classic driver.
> >>
> >> This introduce
On Fri, Feb 21, 2014 at 7:04 PM, Emil Velikov wrote:
> 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 libdrm, you add them t
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 wrote:
>
>> Stéphane Marchesin writes:
>>
>> > On systems without libudev, the loader_get_pci_id_for_fd() c
On Thu, Jan 30, 2014 at 12:07 AM, Eric Anholt wrote:
> Stéphane Marchesin 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 nam
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 modul
On Tue, Jan 28, 2014 at 2:13 PM, Ian Romanick 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 before configuring
On Fri, Jan 24, 2014 at 4:32 AM, Pekka Paalanen 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 is swap inte
dd
>>
>> CC: mesa-sta...@lists.freedesktop.org
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70740
>> Signed-off-by<https://bugs.freedesktop.org/show_bug.cgi?id=70740Signed-off-by>:
>> Stéphane Marchesin
>> Signed-off-by: Chad Versace
>> ---
&
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
wrote:
> ---
> src/gallium/drivers/i915/i915_resource_buffer.c
On Thu, Nov 7, 2013 at 1:22 PM, Dave Airlie wrote:
> On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick wrote:
> > From: Ian Romanick
> >
> > The enumerated values are currently allocated from Intel's range.
>
> Some highlevel comments below,
>
>
> > +GLX renderer attribute number de
On Wed, Nov 6, 2013 at 5:43 PM, Matt Turner 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 the xorg target
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 wrote:
>
>> Hi, Stéphane.
>>
>> No we should not revert to the old behavior. The old behavior was
>> incorr
On Wed, Sep 4, 2013 at 12:46 PM, Zack Rusin 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 injected wire
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.
https://bugs.freedesktop.org/show_bug.
On Tue, Sep 3, 2013 at 9:38 PM, Matt Turner wrote:
> On Tue, Sep 3, 2013 at 8:20 PM, Stéphane Marchesin
> 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 a
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 wrote:
> Bef
On Mon, Aug 12, 2013 at 3:05 PM, Marek Olšák wrote:
> On Mon, Aug 12, 2013 at 11:36 PM, Stéphane Marchesin
> wrote:
>>> Other than hybrid systems (of which
>>> there are none with i915 graphics), is there any case where
>>> __DRI_IMAGE_USE_SHARE can occur?
>
On Mon, Aug 12, 2013 at 2:29 PM, Ian Romanick 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
>>
>>
On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie wrote:
> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
> wrote:
>> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke
>> wrote:
>>> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
>>>>
>>>> O
On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke wrote:
> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
>>
>> On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
>>>
>>> We keep having to pass the attachments around with our gl_renderbuffers
>>> be
On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
> We keep having to pass the attachments around with our gl_renderbuffers
> because that's the only way to find what the gl_renderbuffer actually
> refers to. This is a step toward removing that (though drivers still need
> the Zoffset as well)
gt; get_image(dPriv, x, y, w, h, map);
>
> - /* The pipe transfer has a pitch rounded up to the nearest 64 pixels. */
> - ximage_stride = w * cpp;
> + /* The pipe transfer has a pitch rounded up to the nearest 64 pixels.
> + get_image() has a patch rounded up to 4 byt
rrect cut-off value by 0x3f80,
> which
> 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
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
wrote:
> The coordinates need to be inverted between glX and gallium.
> ---
> src/gallium/
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
b/src/gallium/state_trackers/glx/xlib
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 1006
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
> Reviewed-by Stéphane Marchesin
> ---
> src/gall
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.
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
wrote:
> Module: Mesa
> Branch: mas
On Sat, Mar 9, 2013 at 1:35 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca wrote:
>> > Looks a sensible thing to do.
>> >
>> > Reviewed-by: Jose Fonseca
>> >
>>
>> Thanks for the review.
>>
>> > Any insight how the caller can be fixed
On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca wrote:
> Looks a sensible thing to do.
>
> Reviewed-by: Jose Fonseca
>
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 samplers on top of the max
samplers from
he commit message of 67ef7559: this code should be compiled when
> using the DRI state tracker. In order to do so, the HAVE_*_DRI
> conditionals must be moved after the last assignment of HAVE_COMMON_DRI.
Tested-by: Stéphane Marchesin
> ---
> configure.ac | 19 ++-
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 mod
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
--- a/src/glx/dri2_
DEX (-1) if you ask for the location
> of a non-existent array element, as it should.
>
> Signed-off-by: Frank Henigman
Reviewed-by: Stéphane Marchesin
> ---
> src/mesa/main/uniform_query.cpp | 26 +-
> 1 files changed, 13 insertions(+), 13 deletions
On Wed, Dec 12, 2012 at 3:49 PM, Roland Scheidegger 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), the problem is
On Thu, Oct 25, 2012 at 8:10 AM, Paul Berry wrote:
> On 24 October 2012 12:01, Stéphane Marchesin
> wrote:
>>
>> Hi Paul,
>>
>> This change regresses instanced_arrays with i915g, and probably with
>> llvmpipe as well. Could you take a look?
>>
>&
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 wrote:
> There's no reason to have separate slots in the dispatch table for
> these two functions, since they are
On Thu, Oct 11, 2012 at 3:00 PM, Marek Olšák wrote:
> On Thu, Oct 11, 2012 at 10:05 PM, Stéphane Marchesin
> wrote:
>> On Tue, Oct 9, 2012 at 6:04 PM, Marek Olšák wrote:
>>> Hi,
>>>
>>> this is actually a very small cleanup that got unexpectedly big.
On Tue, Oct 9, 2012 at 6:04 PM, Marek Olšák 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:
> http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg17930.html
>
> The
I'd like to cherry-pick this into 9.0, any objections?
Stéphane
On Fri, Sep 14, 2012 at 10:09 AM, Marek Olšák wrote:
> ---
> src/gallium/auxiliary/util/u_blitter.c | 168
> +---
> src/gallium/auxiliary/util/u_blitter.h |2 +
> 2 files changed, 111 insertions(+
On Mon, Oct 8, 2012 at 6:25 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Sun, Oct 7, 2012 at 3:37 PM, Stéphane Marchesin
>> wrote:
>> > On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca
>> > wrote:
> [...]
>> >> I can&#x
On Sun, Oct 7, 2012 at 3:37 PM, Stéphane Marchesin
wrote:
> On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca wrote:
>>
>>
>> - Original Message -
>>> Am 18.07.2012 07:11, schrieb Marek Olšák:
>>> > On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegge
On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> Am 18.07.2012 07:11, schrieb Marek Olšák:
>> > On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegger
>> > wrote:
>> >> Am 17.07.2012 23:49, schrieb Stéphane March
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 di
On Sat, Sep 8, 2012 at 2:52 PM, Marek Olšák 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 hardware
> -
On Fri, Sep 7, 2012 at 8:19 AM, Matt Turner wrote:
> On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca wrote:
>> - Original Message -
>>> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca
>>> wrote:
>>> > Matt,
>>> >
>>> > I see you went ahead and just disabled it. Please remove it all
>>> > toge
On Tue, Sep 4, 2012 at 4:01 PM, Brian Paul 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
>>> wrote:
>>>>
>>>> On 0
On Tue, Sep 4, 2012 at 3:27 PM, Ian Romanick wrote:
> On 09/04/2012 03:19 PM, Stéphane Marchesin wrote:
>>
>> On Tue, Sep 4, 2012 at 2:59 PM, Eric Anholt wrote:
>>>
>>> Stéphane Marchesin writes:
>>>
>>>> The current computation for
On Tue, Sep 4, 2012 at 3:08 PM, Brian Paul 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
>>
On Tue, Sep 4, 2012 at 2:59 PM, Eric Anholt wrote:
> Stéphane Marchesin 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.
>>
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 deleti
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 a/s
On Mon, Aug 27, 2012 at 2:48 PM, Kenneth Graunke 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|2 --
>>
On Mon, Aug 27, 2012 at 8:58 PM, Kenneth Graunke wrote:
> On 08/27/2012 03:00 PM, Stéphane Marchesin wrote:
>> On Mon, Aug 27, 2012 at 2:24 PM, Kenneth Graunke
>> wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: 87cdefed405da1a57a00
On Mon, Aug 27, 2012 at 2:24 PM, Kenneth Graunke
wrote:
> Module: Mesa
> Branch: master
> Commit: 87cdefed405da1a57a006737297d20ba0c25fa1b
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=87cdefed405da1a57a006737297d20ba0c25fa1b
>
> Author: Kenneth Graunke
> Date: Sun Aug 26 00:07:
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
---
src/glsl/link_uniforms.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca 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 dominated by integer
On Fri, Jul 13, 2012 at 5:03 AM, Jose Fonseca wrote:
> - Original Message -
>> On Thu, Jul 12, 2012 at 08:50:13PM +0100, jfons...@vmware.com wrote:
>> > From: José Fonseca
>> >
>> > Tested by running piglit draw-instanced, and by forcing llvmpipe
>> > advertise no native
>> > integer supp
On Tue, Jul 10, 2012 at 9:04 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca
>> wrote:
>> > Yep. The interfaces are busted.
>> >
>> > Without native integers we get
>> >
>> >DCL SV[0], INSTANCEID
>> >...
>> >ARL ADDR[0].x, SV
On Fri, Jun 29, 2012 at 3:49 PM, Olivier Galibert 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 :)
>
> J
On Fri, Jun 29, 2012 at 3:02 PM, Olivier Galibert 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,
>>
1 - 100 of 198 matches
Mail list logo
