Hi,
I thought mesa was C++ by now? That API is really C-ish.
OG.
On Wed, Feb 18, 2015 at 2:12 AM, Kenneth Graunke wrote:
> On Friday, February 06, 2015 04:00:10 PM Eric Anholt wrote:
>> v2: Rebase on the nir_opcodes.h python code generation support.
>> v3: Use SSA values, and set an appro
Hi,
SHA1 is easy to implement. If you want an always-working backup, I
have a couple of C versions I wrote myself. Libraries are only
interesting if they offer significant speedups through cpu-dependance.
Especially since the shader cache is not in the happy fun land of
hardware-based attacks
Note that ~0U is perfectly correct w.r.t the GLES3 spec. It just
means that s=32, which happens to be greater or equal to 8.
Best,
OG.
On Tue, Dec 16, 2014 at 8:58 AM, Eduardo Lima Mitev wrote:
> On 12/15/2014 08:30 PM, Ian Romanick wrote:
>> On 12/15/2014 08:04 AM, Eduardo Lima Mitev wrote
Hi,
Something is not clear to me: In which way -1 is incorrect?
Also, w.r.t comments, what you're doing is masking, not clamping,
which incidentally is a good thing since clamping would be severely
bad for stencil.
Best,
OG.
On Thu, Dec 11, 2014 at 11:34 PM, Eduardo Lima Mitev wrote:
> Ste
ma Mitev wrote:
>> On 12/18/2014 09:55 AM, Olivier Galibert wrote:
>>> Something is not clear to me: In which way -1 is incorrect?
>>>
>>
>> Hi Olivier,
>>
>> The values being queried are the front and back stencil masks. Masks are
>> (concep
se, but some of the above mention libraries
> are not trivial to install.
>
> The other alternative is to disable shader cache when no suitable dependency
> is found. That is, make this an optional dependency.
>
> Jose
>
> ___
> m
Hi,
Not sure there's anything to maintain, but sure, I'll maintain it.
Best,
OG.
On Sun, Dec 21, 2014 at 8:51 PM, Emil Velikov wrote:
> On 20 December 2014 at 14:21, Olivier Galibert wrote:
>> Here is an implementation I've written myself, so no licens
Sorry for not replying earlier, I didn't see your answer.
On Thu, Sep 4, 2014 at 12:33 AM, Matt Turner wrote:
> Did you change the leading whitespace on purpose?
Not really, I can un-change that. I have an emacs config that's
supposedly what mesa wants, but it may be incorrect.
>> - } suppo
Applied.
OG.
On Fri, Sep 26, 2014 at 6:11 PM, Erik Faye-Lund wrote:
> Our current atan()-approximation is pretty inaccurate at 1.0, so
> let's try to improve the situation by doing a direct approximation
> without going through atan.
>
> This new implementation uses an 11th degree polynomial t
7, 2016 at 2:51 AM, Jason Ekstrand wrote:
> On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert
> wrote:
>>
>> Hi,
>>
>> I'm getting gpu hangs with the lunarg examples (cube and tri) on my
>> Haswell (64 bits). I attach /sys/class/drm/card0/error fwiw. Ho
Ok, I'll do that, thanks :-) No matter what, I'll learn interesting things.
OG.
On Wed, Feb 17, 2016 at 4:31 PM, Jason Ekstrand wrote:
> On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert
> wrote:
>>
>> I'm actually interested about how one goes about debu
; On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert
> wrote:
>>
>> I'm actually interested about how one goes about debugging that kind
>> of problem, if you have pointers. I would have an idea or two on how
>> to go about it if it was in userspace only, but once it
Beware of path issues, vk* has no error checking and gives funky
values to the driver if it fails at finding its extra files.
OG.
On Tue, Mar 1, 2016 at 10:10 AM, Martin Peres wrote:
> On 29/02/16 20:48, Jason Ekstrand wrote:
>
> On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert
ote:
>>
>> On 29/02/16 20:48, Jason Ekstrand wrote:
>>>
>>> On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert >> <mailto:galib...@pobox.com>> wrote:
>>>
>>> Ok, I can tell you that 3DSTATE_DEPTH_BUFFER and
>>> 3DSTATE_STENC
Hi,
That patch makes glDrawBuffer(0, NULL); segfault because
_mesa_drawbuffers expects buffers[0] to be valid. Note that the bug
is there, but I'm not sure what the final setup should look like in
that case.
Best,
OG.
PS: reported by haagch on irc
On Fri, Aug 8, 2014 at 11:20 PM, Brian P
And don't forget that explicit vec4 becomes immensely amusing once you
add fp64/double to the problem.
OG.
On Wed, Aug 20, 2014 at 4:01 PM, Francisco Jerez wrote:
> Connor Abbott writes:
>
>> On Tue, Aug 19, 2014 at 11:33 PM, Francisco Jerez
>> wrote:
>>> Connor Abbott writes:
>>>
On
Signed-off-by: Olivier Galibert
---
src/mesa/main/getstring.c | 6 ++
src/mesa/main/version.c | 140 +-
2 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index 431d60b..f9d13a7
This adds all the extension names and numbers, adds some missing
numbers and fixes the order in places. Future extension additions
should be slightly easier by not requiring to find where it should go
anymore.
Signed-off-by: Olivier Galibert
---
src/mapi/glapi/gen/gl_API.xml | 804
Signed-off-by: Olivier Galibert
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/glsl_parser_extras.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 490c3c8..87d4846 100644
--- a/src/glsl
In that case staying as close as possible to spir may make sense?
OG.
On Fri, Aug 22, 2014 at 5:08 AM, Dave Airlie wrote:
> On 22 August 2014 12:46, Jason Ekstrand wrote:
>> On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote:
>>>
>>> On 21 August 2014 19:10, Henri Verbeet wrote:
>>> > On 2
uot;. That's just clutter.
>
> On 08/21/2014 05:02 AM, Olivier Galibert wrote:
>> Signed-off-by: Olivier Galibert
>> ---
>> src/mesa/main/getstring.c | 6 ++
>> src/mesa/main/version.c | 140
>> +-
&
Hi,
They've been revieved, they've been changed when requested :-)
Best,
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Olivier Galibert
Reviewed-by: Brian Paul
---
src/gallium/drivers/softpipe/sp_tex_sample.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index d4c0175..f29a6c7
.
Signed-off-by: Olivier Galibert
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 144 +--
1 file changed, 113 insertions(+), 31 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
Signed-off-by: Olivier Galibert
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/draw/draw_llvm.c | 32 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 13 +++--
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 11 +---
src/gallium/drivers
nceID for now, as the previous code)
- correctly handle the expected type in emit_fetch_system_value
Signed-off-by: Olivier Galibert
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 11 +--
src/ga
On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote:
> Could you give more background on why is this necessary?
>
> This will make software renderering slower, so I'd really like to avoid it on
> llvmpipe if at all possible.
Well, given the existence of textureLod and textureGrad every
On Wed, Jun 20, 2012 at 01:44:14PM +0100, Roland Scheidegger wrote:
> A lot of code I just glossed over it, but seems to look ok other than
> the (performance) implications this might have.
Actually whether there's a performance implication is not obvious. In
practice the code just kicks the 4-p
On Thu, Jun 21, 2012 at 11:19:39AM +0200, Michel Dänzer wrote:
> On Die, 2012-06-19 at 17:18 -0700, Kenneth Graunke wrote:
> > Also, distribute the appropriate emacs and vim settings to indent things
> > correctly.
>
> In any case, please do this *before* any kind of cleanup.
(global-set-key [(c
On Thu, Jun 21, 2012 at 11:58:57AM +0200, Michel Dänzer wrote:
> On Don, 2012-06-21 at 11:38 +0200, Olivier Galibert wrote:
> > On Thu, Jun 21, 2012 at 11:19:39AM +0200, Michel Dänzer wrote:
> > > On Die, 2012-06-19 at 17:18 -0700, Kenneth Graunke wrote:
> > > > Al
it.
commit edc7b26b03c0393582ff5ec8c963207c7553850a
Author: Olivier Galibert
Date: Thu Jun 21 19:37:11 2012 +0200
clip_init_state: Handle the case when there isn't a fragment shader.
Signed-off-by: Olivier Galibert
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_p
That old bug was hidden but the clipper always interpolating in 3d
space no matter what it should have been doing. Now that the
interpolation has been fixed, the bug shows up.
Fixes bugzilla 51364.
Signed-off-by: Olivier Galibert
diff --git a/src/mesa/state_tracker/st_program.c
b/src
, but
they mostly have their own extension anyway. And the overall picture
ain't so bad.
Signed-off-by: Olivier Galibert
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 40037a5..5eb826e 100644
--- a/src/gallium/drivers/llvmpipe/lp_scr
On Fri, May 18, 2012 at 08:55:39AM -0600, Brian Paul wrote:
> In any case, I think this function could be moved into u_math.c so it
> could be used elsewhere.
[...]
> I was looking at the GLSL round() and roundEven() functions. The GLSL
> spec says round() can use whatever method is fastest. Bu
It can be argued it makes to sense to advertise an integer system
variable in GLSL levels where integers aren't handled.
Signed-off-by: Olivier Galibert
---
I don't really know if that's a patch we want, but otoh having
gl_InstanceIDARB being a different type depending on t
Hi,
I've just finished two piglit runs of llvmpipe with glsl 1.40 and gl
3.1 forced on, one with LLVM 2.9, the other with 3.1.
The least we can say is that there aren't many differences.
- fp-indirections2, didn't have the patience to wait to see whether it
would eventually stop. Looks lik
The type is the destination type (i.e. float vector) and not the
source type. Fixes piglit fs-{in,de}crement-uint.
Signed-off-by: Olivier Galibert
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary
Brilinear folding must only be used if the log2 was computed with
brilinear too. Fixes fs-textureLod-miplevels.
Signed-off-by: Olivier Galibert
---
src/gallium/auxiliary/gallivm/lp_bld_sample.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm
On Mon, Jun 25, 2012 at 05:34:25AM -0700, Jose Fonseca wrote:
> - Original Message -
> > That capability requires integer handling and that's not yet active,
> > ending with a failure in draw-non-instanced unless you force it on.
> > See bug 51366.
> >
> > Frankly, I'd rather have that
On Mon, Jun 25, 2012 at 07:31:20PM +0100, Roland Scheidegger wrote:
> Does this fix the test because lp_build_brilinear_lod produces bogus
> values in this case or just because the test is strict about such
> filtering optimizations? In the latter case I'm not sure I really see
> much point.
Bo
On Mon, Jun 25, 2012 at 11:40:08AM -0700, Jose Fonseca wrote:
> My thoughts too.
>
> Brilinear filtering provides a significant boost, and I don't see why skip
> the optimization for explicit lod over implicit lods.
Warning: code misread :-)
Explicit lod does not need brilinear filtering becaus
On Mon, Jun 25, 2012 at 03:16:35PM -0700, Jose Fonseca wrote:
> Indeed lp_build_brilinear_lod is not faster than
> lp_build_ifloor_fract, but brilinear is faster, not because log is a
> faster approximation, but because it increases the odds that fract
> part is zero, which means that we can sample
On Tue, Jun 26, 2012 at 02:46:01PM -0600, Brian Paul wrote:
> As with the previous commit for softpipe.
>
> v2: remove 'default' case to get compile-time warning
> ---
> src/gallium/drivers/llvmpipe/lp_screen.c | 52 +++--
> 1 files changed, 48 insertions(+), 4 deletions
On Wed, Jun 27, 2012 at 03:17:05AM -0700, Jose Fonseca wrote:
> I took a look at the results, and it seems to me that bri linear
> code is fine -- the test is merely too strict, and doesnot forgive
> the gravitation towards integer lod that brilinear implements.
Yes, the current code maps [0,.25]
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 want to untangle, so I'll revert both 3/4 and 4/4.
You realize that will re-b
be tried out and
shaken for bugs (subsystem trees, -next, akp patch tree, etc). I'm
not sure Mesa can afford it.
That said, try this.
commit 56555c58d7f16c8d619c21feb23096155e2fb505
Author: Olivier Galibert
Date: Sat Jun 30 00:41:20 2012 +0200
lp_bld_tgsi_soa: Fix conversion of s
Hi,
This is the first part of the fixes I've done to make my gm45 work
correctly w.r.t clipping and interpolation. There's a fair chance
they work for everything gen 4/5, but I have no way to be sure.
[PATCH 1/5] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
[PATCH 2/5] intel gen4-5: Compute t
you. The code instead picks whatever slot
was written to by the vertex shader. That makes most of the generated
piglit tests useless to test the backface selection though.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 18 +-
src/mesa/drivers/dri/i965
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip.c| 82 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965/brw_context.h | 59
would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
src/mesa/dr
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip.c | 10 -
src/mesa/drivers/dri/i965/brw_clip.h |6 +--
src/mesa/drivers/dri
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 133 ++---
3 files
On Mon, Jul 02, 2012 at 06:44:37AM -0700, Jose Fonseca wrote:
> But I think that this fix is too ad-hoc, and I suspect it may
> introduce other regressions.
>
> If I understood the problem correctly, the issue here is that some
> drivers want system values in floats, others want in
> integers. Rig
On Tue, Jul 03, 2012 at 12:39:47PM -0700, Jose Fonseca wrote:
> Note that all registers are stored as floats (for convenience, and
> because LLVM has no unions), so integers are bitcasted into floats
> while storing/loading. And I'm not sure if your patch would break
> that.
I did test the patch
On Wed, Jul 04, 2012 at 01:59:44PM +0200, Marek Ol??ák wrote:
> Please disregard patch 1 and 2. It wouldn't work.
What's wrong with them?
> I still plan to commit patch 3.
Patch 3 makes sense. I probably should have done it like that in the
first place (learned a lot since :-).
OG.
On Tue, Jul 10, 2012 at 03:51:22PM +0200, Marek Ol??ák wrote:
> I just wanted to tell you Stephane's change cannot work and it even
> has no effect at the moment. The native integer support is global in
> core Mesa. It's because integer uniforms are converted to floats based
> on the global NativeI
On Tue, Jul 10, 2012 at 09:19:05AM -0700, Stéphane Marchesin wrote:
> There is also option 3): revert the two patches causing the regression.
And then you'll have this problem again as soon as you want llvmpipe
to reach GL 3.00+/GLSL 1.30+. So why not find a definitive solution
now?
Previous cod
On Wed, Jul 11, 2012 at 12:51:32PM +0200, Marek Ol??ák wrote:
> Dude, you should really learn GLSL. The idea to emulate integers is
> even older than the GLSL itself. It first appeared in HLSL and NVIDIA
> Cg on hardware that wasn't even GL2-capable.
I'm learning 3.30+, which is what I consider us
On Wed, Jul 11, 2012 at 02:19:02PM +0200, Marek Ol??ák wrote:
> On Wed, Jul 11, 2012 at 1:09 PM, Jose Fonseca wrote:
> > My current plan is to:
> > - make it clear that INSTANCEID/VERTEXID always means integer
> > - require PIPE_SHADER_CAP_INTEGERS to be advertise in the vertex shader
> > stage i
On Sat, Jun 30, 2012 at 08:50:10PM +0200, Olivier Galibert wrote:
> This is the first part of the fixes I've done to make my gm45 work
> correctly w.r.t clipping and interpolation. There's a fair chance
> they work for everything gen 4/5, but I have no way to be sure.
So, n
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 support, which now produces:
Looks like a very good solution to me. Did you check
draw-non-instanced to
On Wed, Jun 20, 2012 at 08:33:38AM -0600, Brian Paul wrote:
> Yeah, I think it's pretty clear that we need to support per-pixel LOD
> selection. For softpipe, Olivier's big patch looks good.
... and then nothing happened. Ping? The only code remark was a
whitespace issue on one line :-)
> Fo
On Fri, Jul 13, 2012 at 02:45:10PM -0700, Kenneth Graunke wrote:
> Sorry...been really busy, and most of us haven't actually spent much if
> any time in the clipper shaders. I'll try and review it within a week.
Ok cool, lack of time is something I completely understand :-)
> Despite the lack o
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
> Can you split this into three separate patches? That will make it easier
> to troubleshoot in case we find bugs with these patches in the future.
I'm going to try.
> Also, I'm not convinced that #3 is necessary. Is there something i
On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
> Also, I'm not convinced that #3 is necessary. Is there something in the
> spec that dictates this behaviour? My reading of the spec is that if the
> vertex shader writes to gl_BackColor but not glFrontColor, then the
> contents of gl_C
On Tue, Jul 17, 2012 at 03:41:44PM -0600, Brian Paul wrote:
> On 07/13/2012 10:30 AM, Olivier Galibert wrote:
> > On Wed, Jun 20, 2012 at 08:33:38AM -0600, Brian Paul wrote:
> >> Yeah, I think it's pretty clear that we need to support per-pixel LOD
> >> selecti
ed by the sampler.
Signed-off-by: Olivier Galibert
---
src/gallium/drivers/softpipe/sp_tex_sample.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Brown paper bag time. I had tested with (I think) everything with
"tex" in the name. Guess what fbo-cubemap doesn
On Thu, Jul 19, 2012 at 10:57:38AM -0600, Brian Paul wrote:
>
> static const float ...
Indeed.
> Reviewed-by: Brian Paul
Thanks. Could you commit it please?
Best,
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedes
Hi,
This is the second verion of the clipping/interpolation patches.
Main differences:
- I tried to take all of Paul's remarks into account
- I exploded the first patch in 4 independant ones
- I've added a patch to ensure that integers pass through unscathed
Patch 4/9 is (slightly) controversi
In some cases the fragment shader view of the vue registers was out of
sync with the builder. This fixes it.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 -
src/mesa/drivers/dri/i965/brw_wm_pass2.c | 10 +-
2 files changed, 17 insertions
This patch is mostly designed to make followup patches simpler, but
it's a simplification by itself.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_sf_emit.c | 93 +--
1 file changed, 52 insertions(+), 41 deletions(-)
diff --git a/src
Previous code only selected two side in pure fixed-function setups.
This version also activates it when needed with shaders programs.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers
most of the generated piglit tests useless to test the
backface selection, but it's simple and it works.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 +
src/mesa/drivers/dri/i965/brw_wm_pass2.c |9 +
2 files changed, 18 insertions(+)
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip.c| 90 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965/brw_context.h | 11
would require putting
brw_wm_prog before brw_clip_prog and brw_sf_prog. This may be a good
thing, but it could have unexpected consequences, so it's better be
done independently in any case.
Signed-off-by: Olivier Galibert
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_f
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip.c | 13 --
src/mesa/drivers/dri/i965/brw_clip.h |
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 147
This patch ensures that integers will pass through unscathed. Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip_util.c | 48
On Fri, Jul 20, 2012 at 10:01:03AM -0700, Eric Anholt wrote:
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > index 3f98137..3b62952 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > @@ -972,
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index f215b90..0aeb8e2 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -1950,8 +1950,8 @@ mip_filter_linear_2d_linear_repeat_POT(
[Sorry, mail was down yesterday]
On Tue, Jul 24, 2012 at 10:06:05AM -0600, Brian Paul wrote:
> Does this fix bug 52369?
Yes.
> Do you need me to commit this for you?
Yes please. Perhaps I should see about getting a fdo account.
Best,
OG.
___
me
On Thu, Jul 26, 2012 at 10:22:26AM -0700, Eric Anholt wrote:
> I don't like seeing this data that should be referenced out of the
> program cache key being communicated through brw->.
What would you like it being communicated through?
OG.
___
mesa-dev
On Thu, Jul 26, 2012 at 10:18:01AM -0700, Eric Anholt wrote:
> Olivier Galibert writes:
>
> > In some cases the fragment shader view of the vue registers was out of
> > sync with the builder. This fixes it.
>
> s/builder/SF outputs/ ?
>
> I'd love to see
On Thu, Jul 26, 2012 at 05:27:43PM -0700, Eric Anholt wrote:
> As we get into supporting GL 3.x core, we come across more and more features
> of the API that depend on the version number as opposed to just the extension
> list. This will let us more sanely do version checks than "(VersionMajor ==
On Fri, Jul 27, 2012 at 10:40:28AM -0500, Bryan Cain wrote:
> https://github.com/Plombo/mesa/tree/geometry-shaders .
Quick remarks from a fast read:
- you missed draw_pipe_clip.c:clip_init_state, where you need to plug
in the gs info where appropriate. Should be easy. It will take
care of th
On Fri, Jul 27, 2012 at 10:49:19AM -0700, Kenneth Graunke wrote:
> It's more convenient to use shortcuts like glsl_type::bvec2_type than
> the longwinded glsl_type::get_instance(GLSL_TYPE_BOOL, 2, 1).
Yay, code in zones I understand :-)
Reviewed-by: Olivi
On Fri, Jul 27, 2012 at 10:49:20AM -0700, Kenneth Graunke wrote:
> +/**
> + * Convert sampler type attributes into an index in the sampler_types array
> + */
> +#define SAMPLER_TYPE_INDEX(dim, sample_type, array, shadow) \
> + ((unsigned(dim) * 12) + (sample_type * 4) + (unsigned(array)
gt; To get a vector, use columns = 1.
Reviewed-by: Olivier Galibert
That's an obvious bugfix. If there's a stable branch with the glsl
compiler in, it probably should go there.
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Fri, Jul 27, 2012 at 10:49:23AM -0700, Kenneth Graunke wrote:
> From: Ian Romanick
>
> This matches the typeless constructors for unop and binop
> ir_expressions.
>
> Signed-off-by: Ian Romanick
> Reviewed-by: Kenneth Graunke
> ---
> src/glsl/ir.cpp | 17 +
> src/glsl/ir.h
+++ b/src/glsl/ir.h
> @@ -1027,7 +1027,7 @@ enum ir_expression_operation {
> /**
> * A sentinel marking the last of all operations.
> */
> - ir_last_opcode = ir_last_binop
> + ir_last_opcode = ir_quadop_vector
> };
Another obvious-in-hindsight bugfix.
Reviewed-by: Olivi
On Fri, Jul 27, 2012 at 10:49:25AM -0700, Kenneth Graunke wrote:
> From: Ian Romanick
>
> There can only be one variable used in an ir_quadop_vector. Accesses
> of this variable must be swizzled.
There's nothing anywhere ensuring the presence of the swizzle. I
completely agree that trashing th
On Tue, Jul 17, 2012 at 07:37:43AM -0700, Paul Berry wrote:
> If possible, I would still like to think of a way to address this situation
> that (a) doesn't require modifying both fragment shader back-ends and the
> SF program, and (b) helps all Mesa drivers, not just Intel Gen4-5.
> Especially bec
On Mon, Jul 30, 2012 at 10:30:57AM -0700, Eric Anholt wrote:
> I'm perfectly fine with the VUE containing slots for both when the app
> has gone out of its way to ask for deprecated two-sided color
> rendering.
Are you also ok with recompiler the shaders when that enable is
switched?
OG.
_
as already been lexed as a NEW_IDENTIFIER
before _mesa_glsl_initialize_types is called.
Signed-off-by: Olivier Galibert
---
src/glsl/glsl_parser.yy |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 64506b6..9a0af95 10
No hookup with GL yet. Planned to be used to simplify profiles.
Signed-off-by: Olivier Galibert
---
src/glsl/ast.h | 12 ++-
src/glsl/glcpp/glcpp-lex.l | 135 --
src/glsl/glcpp/glcpp-parse.y| 75 +-
src/glsl/glcpp/glcpp.c
as already been lexed as a NEW_IDENTIFIER
before _mesa_glsl_initialize_types is called.
Signed-off-by: Olivier Galibert
---
src/glsl/glsl_parser.yy |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
[Sorry, resent with the correct subject...]
diff --git a/src/glsl/glsl_parser.yy
On Fri, Apr 13, 2012 at 11:06:18AM -0700, Ian Romanick wrote:
> On 04/13/2012 08:47 AM, nobled wrote:
> > Prevents this error with Automake 1.9:
> >
> > src/gallium/drivers/Makefile.am: C objects in subdir but
> > `AM_PROG_CC_C_O' not in `configure.ac'
> > autoreconf: automake failed with exit stat
On Wed, Apr 18, 2012 at 10:05:58AM -0700, Jose Fonseca wrote:
> This idea of passing GLSL IR assumes that GLSL IR would grow to be
> generic enough to represent any shader, and not just GLSL derived
> ones.
What would be missing from a IR covering GLSL 4.2? Some types maybe?
OG.
__
On Wed, Apr 18, 2012 at 06:40:32PM -0700, Eric Anholt wrote:
> +mat3 inverse(mat3 m)
> +{
> + mat3 adj;
> + adj[0][0] = + (m[1][1] * m[2][2] - m[2][1] * m[1][2]);
> + adj[1][0] = - (m[1][0] * m[2][2] - m[2][0] * m[1][2]);
> + adj[2][0] = + (m[1][0] * m[2][1] - m[2][0] * m[1][1]);
> + adj[
Guys, it's a bugfix, it's five lines changed, and it's falling through
the cracks... Can someone have a look?
OG.
On Wed, Apr 11, 2012 at 10:56:51AM +0200, Olivier Galibert wrote:
> Type selection must be extended w.r.t version and extension lines as
> soon as it is poss
1 - 100 of 182 matches
Mail list logo
