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 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
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
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, 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 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 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 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, 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
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 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?
>
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 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
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 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
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
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
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 ++-
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
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
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
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
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
>> ---
&
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
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 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 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 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 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 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
>
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
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.
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
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
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
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/
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
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
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)
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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
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, 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 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
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
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_
On Mon, Dec 5, 2011 at 14:00, Michael Karcher
wrote:
> Hello developers,
>
> trying some sample programs on the i915 gallium based driver, I stumbled
> upon getting black/white rendering in teapot, if using the hardware
> pixel shader backend, but getting correct output (yellow textured base)
> wi
2011/12/5 Michael Karcher :
> Am Montag, den 05.12.2011, 13:03 -0800 schrieb Stéphane Marchesin:
>> > This translation is correct. The mentioned optimization now kicks in
>> > corrrectly removing line 9, but it also reokaces line 6/7 by
>> > 6: R[1].xyz = MUL R[0],
On Fri, Dec 9, 2011 at 14:15, Tom Stellard wrote:
> Hi,
>
> I have just pushed a branch containing an LLVM shader backend for r600g to my
> personal git repo:
>
> http://cgit.freedesktop.org/~tstellar/mesa/ r600g-llvm-shader
>
> There are three main components to this branch:
>
> 1. A TGSI->LLVM c
Applied, thanks!
Stéphane
On Mon, Dec 5, 2011 at 13:02, Michael Karcher
wrote:
> Signed-off-by: Michael Karcher
>
> ---
> src/gallium/drivers/i915/i915_debug.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/i915/i915_debug.c
> b/src/gallium/d
Applied, thanks!
Stéphane
2011/12/11 Fatih Aşıcı :
> ---
> src/gallium/drivers/i915/i915_prim_vbuf.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/i915/i915_prim_vbuf.c
> b/src/gallium/drivers/i915/i915_prim_vbuf.c
> index 79db3b6..3f85466 10
It is #ifdef'd out, and is already called unconditionnaly a couple lines above.
---
src/gallium/drivers/llvmpipe/lp_context.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_context.c
b/src/gallium/drivers/llvmpipe/lp_context.c
index b6
As far as I know, this check has value, why not replace the assert
with something like
ASSERT(_mesa_get_format_bytes(dstFormat) == sizeof(GLuint));
instead? That would silence the warning but keep the check.
Stéphane
On Tue, Jan 3, 2012 at 10:54, Vinson Lee wrote:
> This patch also silences the
Hi Dave,
This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
piglit test on i915g.
Stéphane
On Sat, Jan 7, 2012 at 00:39, Dave Airlie
wrote:
> Module: Mesa
> Branch: master
> Commit: a103c61d278b7f56208818c4b949c408c00286fa
> URL:
> http://cgit.freedesktop.org/mesa/mesa
In the following scenario:
- CreateContext C1
- MakeCurrent C1
- DestroyContext C1 (does not actually destroy the first context, postponed
until the next MakeCurrent)
- CreateContext C2
- MakeCurrent C2
MakeCurrent will call flush on a context which might not even have had a front
buffer, leadin
What about initializing "api" earlier in dri2_convert_glx_attribs
instead? i.e. before the first return. That should fix it also and is
cleaner.
Stéphane
On Tue, Jan 10, 2012 at 21:32, Vadim Girlin wrote:
> Signed-off-by: Vadim Girlin
> ---
>
> Fixes unigine heaven startup problem for me.
>
>
Where else would the flush go? I'll look into fixing it differently
but if the flush is anywhere in the makecurrent path, the same issue
will happen. Again, none of the classic dri drivers do it.
Stéphane
2012/1/11 Jose Fonseca :
> Stephane,
>
> Although flushing the front buffer may be unnecess
On Wed, Jan 11, 2012 at 10:13, Jose Fonseca wrote:
> - Original Message -
>> Where else would the flush go?
>
> Maybe one of the callers already invoked glFlush, or something like that.
>
Not that I could see.
>> I'll look into fixing it differently
>> but if the flush is anywhere in the
On Wed, Jan 11, 2012 at 10:13, Jose Fonseca wrote:
> - Original Message -
>> Where else would the flush go?
>
> Maybe one of the callers already invoked glFlush, or something like that.
>
>> I'll look into fixing it differently
>> but if the flush is anywhere in the makecurrent path, the s
On Tue, Jan 17, 2012 at 15:47, Stéphane Marchesin
wrote:
> On Wed, Jan 11, 2012 at 10:13, Jose Fonseca wrote:
>> - Original Message -
>>> Where else would the flush go?
>>
>> Maybe one of the callers already invoked glFlush, or something like that.
&
I picked those draw changes from Jakob's branch. I discarded the first two
commits (regresses glest) and the last one (i915g specific, works around a bug
that was already fixed properly in git). Gives me a ~10% perf improvement in
state-intensive apps like ipers on i915g.
Checked that the series d
From: Jakob Bornecrantz
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |4
src/gallium/auxiliary/draw/draw_private.h |2 --
src/gallium/auxiliary/draw
From: Jakob Bornecrantz
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_pipe.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe.c
b/src/gallium/auxiliary/draw/draw_pipe.c
index
also has the added benefit of now grouping all pipelined
drawing into a single draw call if the driver uses vbuf_render.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |2 +
src/gallium/auxiliary/draw/draw_private.h |7
From: Jakob Bornecrantz
This could be improved so only the frontend is flushed since it
convertes all indecies to ushots and the fetch part of the middle
always perpares both linear and indexed.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw
From: Jakob Bornecrantz
We could improve this by only flushing the frontend and the fetch part
of the middle. This would avoid recalculating the emit keys.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |3 +++
1 files changed
From: Jakob Bornecrantz
In certain conditions when going from different primitive requires
us to flush and validate the different stages. Like smoth lines being
active but first drawing with triangles and then drawing lines.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
I picked those draw changes from Jakob's branch. I discarded the first two
commits (regresses glest) and the last one (i915g specific, works around a bug
that was already fixed properly in git). Gives me a ~10% perf improvement in
state-intensive apps like ipers on i915g.
Checked that the series d
From: Jakob Bornecrantz
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |4
src/gallium/auxiliary/draw/draw_private.h |2 --
src/gallium/auxiliary/draw
From: Jakob Bornecrantz
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_pipe.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe.c
b/src/gallium/auxiliary/draw/draw_pipe.c
index
commit also has the added benefit of now grouping all pipelined
drawing into a single draw call if the driver uses vbuf_render.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |6 +++
src/gallium/auxiliary/draw/draw_private.h |8
Please ignore that, I forgot to replace it. That said the rest has
been updated :)
Stéphane
2012/1/24 Stéphane Marchesin :
> I picked those draw changes from Jakob's branch. I discarded the first two
> commits (regresses glest) and the last one (i915g specific, works around a bug
1 - 100 of 198 matches
Mail list logo
