defined(_MSC_VER) && !defined(__INTEL_COMPILER)
+# if _MSC_VER >= 1900
+# define HAS_TRIVIAL_DESTRUCTOR(T) __has_trivial_destructor(T)
+# else
#else is redundant her. Otherwise looks good.
Reviewed-by: Jose Fonseca
+# endif
# endif
# ifndef HAS_TRIVIAL
On 07/11/16 22:32, George Kyriazis wrote:
- Added code to create screen and handle swaps in libgl_gdi.c
- Added call to swr SConscript
- included llvm 3.9 support for scons (windows swr only support 3.9 and
later)
- include -DHAVE_SWR to subdirs that need it
To buils SWR on windows, use "scons
On 11/11/16 15:48, Brian Paul wrote:
inttypes.h doesn't always define the PRIx64 macro when compiling C++
code with MinGW. For that case, simply define PRIx64 to be "lx".
This generates a format/argument type mismatch warning. And using
"llx" generates other warnings. Just live with it.
https
/* for PRIx64 macro */
#include "ir.h"
#include "ir_hierarchical_visitor.h"
Looks great. I think that at some point we'll want to define this
globally, in configure.ac / SCons.
Reviewed-by: Jose Fonseca
Jose
___
mesa-
On 10/11/16 17:27, Kyriazis, George wrote:
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Thursday, November 10, 2016 8:14 AM
To: Kyriazis, George
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v2 6/8] gallium: Enable swr driver
"gallium/targets: scons
FALSE,
+ map_ptr,
+ stride, zero, zero,
+ NULL);
+
Comment here would be nice.
Otherwise series looks good. A nice cleanup.
Reviewed-by: Jose Fonseca
+ index_valid = lp_build_broadcast(gallivm, aosi
On 17/11/16 07:37, Andrew A. wrote:
Hello,
I'm using Mesa's software renderer for the purposes of regression
testing in our graphics software. We render various scenes, save a
screencap of the framebuffer for each scene, then compare those
framebuffer captures to previously known-good captures.
On 23/11/16 01:23, Vinson Lee wrote:
Signed-off-by: Vinson Lee
---
scons/llvm.py | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index 977e47a..a27bf00 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -194,11 +194,16 @@ def
onscript
b/src/gallium/drivers/swr/SConscript
index 0de51a7..3f0517b 100644
--- a/src/gallium/drivers/swr/SConscript
+++ b/src/gallium/drivers/swr/SConscript
@@ -31,7 +31,8 @@ if env['platform'] == 'windows':
# on windows there is no llvm-config, so LLVM is defined
llvm_includedi
On 23/11/16 17:37, Emil Velikov wrote:
On 23 November 2016 at 16:14, George Kyriazis wrote:
---
src/gallium/targets/libgl-gdi/SConscript | 1 +
src/gallium/targets/libgl-gdi/libgl_gdi.c | 4
2 files changed, 5 insertions(+)
diff --git a/src/gallium/targets/libgl-gdi/SConscript
b/src/ga
On 29/11/16 14:00, Andrew A. wrote:
On Fri, Nov 18, 2016 at 2:58 AM, Jose Fonseca wrote:
On 17/11/16 07:37, Andrew A. wrote:
Hello,
I'm using Mesa's software renderer for the purposes of regression
testing in our graphics software. We render various scenes, save a
screen
On 29/11/16 14:13, Jose Fonseca wrote:
On 29/11/16 14:00, Andrew A. wrote:
On Fri, Nov 18, 2016 at 2:58 AM, Jose Fonseca
wrote:
On 17/11/16 07:37, Andrew A. wrote:
Hello,
I'm using Mesa's software renderer for the purposes of regression
testing in our graphics software. We rend
I didn't spot any relevant discussion on
http://help.appveyor.com/discussions/problems or
https://appveyor.statuspage.io/
It must have been something transient.
Jose
On 30/11/16 03:52, Brian Paul wrote:
We've had a few instances in the past where complex macro code caused
super long MSVC com
On 05/12/16 19:52, Emil Velikov wrote:
From: Emil Velikov
Analogoust to the previous commit were we did so for autotools
Cc: Jose Fonseca
Signed-off-by: Emil Velikov
---
Jose, I'm not 100% sure if that holds true the compiler(s) that you
gents use. Can you please double-check ?
Thanks
lp_build_const_int_vec(gallivm, dst_type, sv),
"");
+#endif
+ }
+ }
}
return res;
Series looks good to me.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
t for formats or scenarios for which there was no
* opportunity or incentive to optimize.
+*
+* We do NOT want to end up here, this typically is quite terrible,
+* in particular if the formats have less than 4 channels.
+*
+* Right now, this should only be hit for:
+
description chan_desc =
format_desc->channel[i];
+unsigned blockbits = type.width;
+unsigned vec_nr = chan_desc.shift / type.width;
+chan_desc.shift %= type.width;
+
+output[i] = lp_build_extract_soa_chan(&bld,
+ blockbits,
+ FALSE,
+ chan_desc,
+ dst[vec_nr]);
+ }
+ }
+ else {
+ for (i = 0; i < format_desc->nr_channels; i++) {
+output[i] = dst[i];
+ }
+ }
+
+ lp_build_format_swizzle_soa(format_desc, &bld, output, rgba_out);
+ return;
+ }
+
if (format == PIPE_FORMAT_R11G11B10_FLOAT ||
format == PIPE_FORMAT_R9G9B9E5_FLOAT) {
/*
Looks good AFAICT.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
ivm, aos_fetch, inputs, vs_type);
}
- convert_to_soa(gallivm, aos_fetch, inputs, vs_type);
for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
inputs[i] = LLVMBuildBitCast(builder, inputs[i], blduivec.vec_type, "");
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
uct lp_build_sample_context *bld,
lp_build_fetch_rgba_soa(bld->gallivm,
bld->format_desc,
- bld->texel_type,
+ bld->texel_type, TRUE,
bld->base_ptr, offset,
On 12/12/16 00:11, srol...@vmware.com wrote:
From: Roland Scheidegger
We should do transpose, not extract/insert, at least with "sufficient" amount
of channels (for 4 channels, extract/insert shuffles generated otherwise look
truly terrifying). Albeit we shouldn't fallback to that so often in a
On 30/06/16 18:13, Ian Romanick wrote:
I think I might want to use gperf for something in Mesa, but I'm not
100% sure yet. Before I proceed, is it even acceptable to add that as a
build dependency?
I presume C code generated by gperf is freely usable and it's not
subject to GPL, right? (I c
On 02/07/16 10:38, Michel Dänzer wrote:
On 01.07.2016 23:11, Emil Velikov wrote:
On 28 June 2016 at 04:00, Michel Dänzer wrote:
FWIW, +1 for adding .editorconfig files corresponding to the existing
.dir-locals.el files as a first step, so users of other editors can also
get the benefit of the
alue(function);
Reviewed-by: Jose Fonseca
BTW, there are functions in llvmpipe besides instrinsics that never
generate C++ exceptions. We should eventually set this attr on all them
then.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop
AFAICS, this code is only used when USE_X86_ASM/USE_X86_64_ASM. These are
never defined on Windows (we never use the assembly files on Windows,
regardless which compiler is used), therefore there should be no impact to MSVC
or Windows builds.
Acked-by: Jose Fonseca
Jose
PS: Thanks for
On 18/07/16 00:46, Eric Engestrom wrote:
A few weeks ago, Jose Fonseca suggested [0] we use .editorconfig files
to try and enforce the formatting of the code, to which Michel Dänzer
suggested [1] we start by importing the existing .dir-locals.el
settings.
This is a first draft, with settings
On 22/07/16 16:21, Emil Velikov wrote:
On 22 July 2016 at 09:42, Christian König wrote:
Am 22.07.2016 um 03:37 schrieb Rob Clark:
On Thu, Jul 21, 2016 at 9:35 PM, Rob Clark wrote:
On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić
wrote:
LLVM and Mesa both define the DEBUG macro in incompa
(2nd try. 1st email is being held due to size.)
On 21/07/16 18:48, Vedran Miletić wrote:
LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
general practice, we should avoid using such generic names when it is
possible to do so.
This patch renames all occurrences of the DEBUG
_texel_rgba_dxt3 ||
+ !fetch_2d_texel_rgba_dxt5 ||
+ !tx_compress_dxtn) {
debug_printf("couldn't reference all symbols in " DXTN_LIBNAME
", software DXTn compression/decompression "
"unavailable\
libgallium.so was an awful idea.
Just a few days ago we had an internal bug report because libgallium.so
symbols were clashing with the application symbols.
This is because all that libgallium.so export all gallium symbols, even
though they have no unique prefix -- it uses common symbols like
On 03/08/16 09:43, Enrico Weigelt, metux IT consult wrote:
On 03.08.2016 09:47, Timothy Arceri wrote:
The current requirement for Mesa is MSVC 2013 so any compat workarounds
for functionality supported by that version can be dropped.
A bunch of stuff has been dropped already but feel free to f
On 04/08/16 01:48, Enrico Weigelt, metux IT consult wrote:
On 03.08.2016 23:28, Jose Fonseca wrote:
Hi,
There are minor inconsistencies. For example, it doesn't support
__func__, but doing
#define __func__ __FUNCTION__
suffices to make __func__ work compatible.
Wait a second ...
On 04/08/16 11:25, Enrico Weigelt, metux IT consult wrote:
On 04.08.2016 11:38, Jose Fonseca wrote:
__FUNCTION__ has been around for a very long time (before 1999), so it's
no surprise that MSVC has it. But not implementing __func__ does seem a
oversight. I believe they fixed it on MSVC
I believe depth clears should not be affected by pipe_depth_state::writemask.
I suspect that the only reason depth mask is not explicitly enable is because
it is a boolean, unlike color/stencil write mask which are proper bitmasks.
Therefore there is no additional information in depth write mask
Looks good to me. v2 changes seem the right ones.
Jose
- Original Message -
> From: Roland Scheidegger
>
> They need some special handling. Quite complicated.
> Additionally, use the same code for implicit derivatives too if no_rho_approx
> and no_quad_lod is set, because it seems while
Updated series looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Not used since ages, and it wouldn't work at all with explicit derivatives
> now
> (not that it did before as it ignored them but now the code would just use
> the derivs pre-projected which would
Looks good to me!
Jose
- Original Message -
> Both the imul_hi and umul_hi are working with this patch.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 60
> ++
> 1 file changed, 60 insertions(+)
>
> diff --git a/src/gall
- Original Message -
> Am 11.10.2013 16:21, schrieb Brian Paul:
> > On 10/11/2013 07:11 AM, srol...@vmware.com wrote:
> >> From: Roland Scheidegger
> >>
> >> The previous limit of of 128*1024 was reported to cause frequent
> >> recompiles
> >> in some apps due to shader variant thrashing
- Original Message -
> Hi,
>
> I pulled Brian's patches and then hacked llvmpipe locally to claim GL 3.2,
> and ran piglit, fixed some of the obviously missing pieces and crashes.
>
> These aren't immediately going to expose any new functionality, but it
> might help if someone doing r600
The change looks good as far as as I can tell.
Jose
- Original Message -
> Use GL_MAP_INVALIDATE_RANGE, UNSYNCHRONIZED and FLUSH_EXPLICIT flags
> when mapping VBOs during display list compilation. This mirrors what
> we do for immediate-mode VBO building in vbo_exec_vtx_map().
>
> This
Tue, Oct 15, 2013 at 9:15 PM, Dave Airlie wrote:
> > On Tue, Oct 15, 2013 at 7:58 PM, Jose Fonseca wrote:
> >> - Original Message -
> >>> Hi,
> >>>
> >>> I pulled Brian's patches and then hacked llvmpipe locally to claim GL
>
Looks good to me. Thanks for looking into this.
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> During the recent bind_sampler_states() interface change in gallium
> we changed the CSO single_sampler_done() function so that if we were
> decreasing the number of sampl
>
> > Marek
> >
> > On Tue, Oct 15, 2013 at 9:15 PM, Dave Airlie wrote:
> > > On Tue, Oct 15, 2013 at 7:58 PM, Jose Fonseca
> > > wrote:
> > >> - Original Message -
> > >>> Hi,
> > >>>
> > >
tests don't detect this, I guess they just aren't sufficient...
> But we could just say it is supported, and consider this a bug.
>
> Roland
>
>
> Am 16.10.2013 03:14, schrieb Jose Fonseca:
> > Yep, as Marek said, llvmpipe passes all piglit's ARB_depth_cl
I'm going to have to revert this as this patches has a few problems:
- it breaks windows builds becuase env[LLVM_CXXFLAGS] is never set there
- it is merging not only rtti, but the whole cxxflags (defines etc) which has
proven to be a source of troubles (breaks debugging etc.)
Jose
- Origin
I think this patch does what you need, but with much less unintended
side-effects:
$ git diff
diff --git a/scons/llvm.py b/scons/llvm.py
index c1c3736..8388d8e 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -190,6 +190,11 @@ def generate(env):
pass
env.MergeFlags(
Thanks.
Jose
- Original Message -
> * Based on ideas of Jose Fonseca
> * A rework of ce8eadb6e8
> ---
> scons/llvm.py | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/scons/llvm.py b/scons/llvm.py
> index c1c3736..8388d8e 100644
> --- a/scons/ll
Looks good. Thanks.
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> MSVC doesn't have a strcasecmp() function; it uses _stricmp() instead.
> ---
> src/glsl/glsl_parser.yy | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/sr
Looks great AFAICT.
Jose
- Original Message -
> From: Roland Scheidegger
>
> For seamless cube filtering it is necessary to determine new faces and new
> coords per sample. The logic for this is _seriously_ complex (what needs
> to happen is very "asymmetric" wrt face, x/y under/overflo
<< frac_bits));
> }
> /*@}*/
>
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Looks good.
A future improvement could be querying PIPE_CAP_MAX_TEXTURE_2D_LEVELS instead
of using a constant width/height.
Jose
- Original Message -
> Used to test rasterization, because we often breakdown on
> subdivision of triangles with long edges.
>
> Signed-off-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> The layer coming from GS needs to be clamped (not sure if that's actually
> the correct error behavior but we need something) as the number can be higher
> than the amount of layers in the fb. However, this code was using the layer
> c
- Original Message -
> Am 04.11.2013 18:21, schrieb jfons...@vmware.com:
> > From: José Fonseca
> >
> > Just happened to notice it was missing while looking at it.
> > ---
> > src/gallium/auxiliary/util/u_format.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/src/ga
Series looks good AFAICT.
Jose
- Original Message -
> ---
> src/mesa/vbo/vbo_attrib_tmp.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h
> index 02c283d..bbc0205 100644
> --- a/src/mesa/vbo/vb
Looks great to me
Jose
- Original Message -
> From: Roland Scheidegger
>
> SSE can't handle true vector shifts (with variable shift count),
> so llvm is turning them into a mess of extracts, scalar shifts and inserts.
> It is however possible to emulate them in lp_build_minify with floa
Looks good. Though I thought we had fixed this once before.
Could you double check there are no similar issues with the remaining register
files (output, etc)?
Jose
- Original Message -
> From: Roland Scheidegger
>
> We weren't adding the soa offsets when constructing the indices
> f
LGTM.
Jose
- Original Message -
> Since it's helpful to know why the shader did not compile.
> Also, call fflush() for Windows.
> ---
> src/mesa/main/shaderapi.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 7
This change seems makes dri3proto a hard requirement to build with automake.
Is that strictly necessary? I tried to find ubuntu packages for it to install
on my build slave, but it doesn't seem they exist yet.
Jose
- Original Message -
> Module: Mesa
> Branch: master
> Commit: 2d94601
Looks good to me AFAICT.
I had independently pushed a fix similar to the first chunk in your patch. I
think it matches your's verbatim so there should be no conflict when you rebase.
Jose
- Original Message -
> From: Brian Paul
>
> To fix fall-out from recent commits.
> ---
> .../st
- Original Message -
> On Fri, Nov 8, 2013 at 9:55 AM, wrote:
> > From: José Fonseca
> >
> > By disabling DRI3 support for the time being.
> >
> > I'll add DRI3 support to scons build when the DRI3 dependencies become
> > more widely available (as now there is no convenient way of test
I
- Original Message -
> On 11/08/2013 11:49 AM, Eric Anholt wrote:
> > Jose Fonseca writes:
> >
> >> This change seems makes dri3proto a hard requirement to build with
> >> automake. Is that strictly necessary? I tried to find ubuntu
> >> pa
- Original Message -
> I've been banging my head against a wall for a while now on this.
>
> So the Haiku applications that call glViewport(.. for window
> resizes,etc never actually execute the Driver's Viewport call.
> (aka ctx->Driver.Viewport:
> http://cgit.freedesktop.org/mesa/mesa/
The introduction and use of lp_build_clamp_zero_one_nanzero looks good.
I can't comment on the changes to the existing paths though, as they are too
subtle for me. As long there are no regressions I'm good.
Jose
- Original Message -
> From: Roland Scheidegger
>
> d3d10 requires us to
- Original Message -
> On 11/13/2013 10:37 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
> >
> > I had prototyped this for a while while debugging an issue, but finally
> > cleaned this up and added a few more bel
uct svga_hwtnl *hwtnl,
>ret = translate_indices(hwtnl,
>index_buffer,
>start * index_size,
> - gen_nr, gen_size, gen_func, &gen_buf);
> + gen_prim, gen_nr, gen_size, gen_func,
&g
mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=khe58xr9qBVn2
mask.texture = 1;
> }
>
> + if (target == PIPE_TEXTURE_CUBE) {
> + mask.cubeTexture = 1;
> + }
> + if (target == PIPE_TEXTURE_3D) {
> + mask.volumeTexture = 1;
> + }
> +
> return (caps.value & mask.value) == mask.value;
> }
>
>
p_build_tgsi_soa_context *bld,
> res = LLVMBuildLoad(builder, reg_ptr, "");
> } else {
> assert(0);
> +continue;
> }
>
> emit_dump_reg(gallivm, file, index, chan, res);
Reviewed-by: Jose Fonseca
- Original Message -
> - Original Message -
> > From: José Fonseca
> >
> > +t->outputs[i] = ureg_writemask(t->outputs[i],
> > TGSI_WRITEMASK_X);
>
> What happens when the application decides to write to any component other
> than X? The application writemask combined
- Original Message -
> IIRC, all Radeons older than HD 7700 or so can do fixed-function fog,
> but Gallium doesn't have a proper interface for it. There is no
> dedicated shader output though, so r300g and r600g use a texcoord slot
> if there is any left. I think all drivers except
> softpi
- Original Message -
> - Original Message -
> > IIRC, all Radeons older than HD 7700 or so can do fixed-function fog,
> > but Gallium doesn't have a proper interface for it. There is no
> > dedicated shader output though, so r300g and r600g use a texcoord slot
> > if there is any
Looks good to me. Thanks Roland.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Some rounding errors could crop up when calculating a0. Use a more accurate
> method (barycentric interpolation essentially) to fix this, though to fix
> the REAL problem (which is that our interpo
- Original Message -
> Great!
>
> Couple of comments inline.
>
> On 11/21/2013 12:02 AM, Zack Rusin wrote:
> > 8 bit precision is required by d3d10 but unfortunately
> > requires 64 bit rasterizer. This commit implements
> > 64 bit rasterization with full support for 8bit subpixel
> > pre
Thanks for reviewing.
- Original Message -
> On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > These degenerate instructions can often be emitted by state trackers
> > when the semantics of instructions don't match precisely.
> > ---
> > src/gallium/auxil
- Original Message -
> On 11/22/2013 05:29 AM, Zack Rusin wrote:
> >> For me too, other than the fixed_position members, looks good. Thanks for
> >> your perseverance on this Zack!
> >
> > Thanks! ok, attached is a version that makes position and dx/dy 32bit
> > again, it seems to work g
- Original Message -
> On 04/06/14 12:50, Jon TURNEY wrote:
> > On 04/06/2014 01:06, Vinson Lee wrote:
> >> Match the behavior of the SCons MinGW build.
> >>
> >> This patch also fixes these build errors.
> >>
> >>CC glapi_entrypoint.lo
> >> glapi_entrypoint.c: In function 'init
Vinson,
As I said in another reply, I think this the right thing to do on Windows.
Please submit this and drop the "c11: .." patch. Thanks.
Jose
- Original Message -
> Match the behavior of the SCons MinGW build.
>
> This patch also fixes these build errors.
>
> CC glapi_entr
nfo.pfd))
>continue;
>
> - //if(!(pfd.dwFlags & PFD_SUPPORT_OPENGL))
> + //if(!(info.pfd.dwFlags & PFD_SUPPORT_OPENGL))
>// continue;
>
> + if (have_WGL_ARB_pixel_format && have_WGL_ARB_multisample) {
> + int attribs[] = { WGL_SAMPLE_BUFFERS_ARB, WGL_SAMPLES_ARB };
> + int values[2], layer = 0;
> + if (wglGetPixelFormatAttribivARB_func(hdc, i, layer,
> + 2, attribs, values)) {
> +info.sampleBuffers = values[0];
> +info.numSamples = values[1];
> + }
> + else {
> +info.sampleBuffers = 0;
> +info.numSamples = 0;
> + }
> + }
> +
>if (mode == Verbose)
> - print_visual_attribs_verbose(i, &pfd);
> + print_visual_attribs_verbose(i, &info);
>else if (mode == Normal)
> - print_visual_attribs_short(i, &pfd);
> + print_visual_attribs_short(i, &info);
>else if (mode == Wide)
> - print_visual_attribs_long(i, &pfd);
> + print_visual_attribs_long(i, &info);
> }
> printf("\n");
> }
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=mIR8V6P%2FYoxEbnhUZudn2DC8YBTiHYlMkU%2FRwIHNl6I%3D%0A&s=62e7dd68a5ab08412f68fbcd48475f3f35c3aa10cd4290d53f30b4632ab3b800
>
Series is
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> On 06/09/2014 07:22 AM, Jose Fonseca wrote:
> > I don't think that OpenGL ICD should advertise multi-sample formats via the
> > standard DescribePixelFormat.
> > http://www.opengl.org/registry/specs/ARB/wgl_pixel_format.txt states:
> &g
- Original Message -
> On 06/09/2014 11:38 AM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> On 06/09/2014 07:22 AM, Jose Fonseca wrote:
> >>> I don't think that OpenGL ICD should advertise multi-sample formats v
uct cmd_bin;
> /* Rasterizer output size going to jit fs, width/height */
> #define LP_RASTER_BLOCK_SIZE 4
>
> -#define LP_MAX_ACTIVE_BINNED_QUERIES 16
> +#define LP_MAX_ACTIVE_BINNED_QUERIES 64
>
> #define IMUL64(a, b) (((int64_t)(a)) * ((int64_t)(b)))
>
> --
>
On 17/06/14 13:58, srol...@vmware.com wrote:
From: Roland Scheidegger
Such conversions (which are most likely rather pointless in practice) were
resulting in shifts with negative shift counts and shifts with counts the same
as the bit width. This was always undefined in llvm, the code generated
Looks good to me AFAICT. Thanks for the update.
Jose
From: srol...@vmware.com
Sent: 18 June 2014 00:36
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: fix SCALED -> NORM conversions
From: Rol
Looks good. Thanks Roland.
Jose
From: srol...@vmware.com
Sent: 19 June 2014 02:28
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: set mcpu when initializing llvm execution engine
From: Roland Scheidegger
LGTM.
Jose
From: srol...@vmware.com
Sent: 23 June 2014 21:08
To: Jose Fonseca; mesa-dev@lists.freedesktop.org; imir...@alum.mit.edu
Cc: Roland Scheidegger; 10.1 10.2
Subject: [PATCH] draw: (trivial) fix clamping of viewport index
From: Roland Scheidegger
On 15/07/14 15:39, Brian Paul wrote:
Before, we always reported zeros in the multisample columns of the
format list. Since PIXELFORMATDESCRIPTOR doesn't have fields for
multisample, we use a new format_info structure to extend that type.
We can only query this info with the wglGetPixelFormatAtt
Hi Mathias,
Thanks for doing this.
Patch 2 looks great.
For patch 1 I'd prefer that instead of keeping a global list of
contexts, these are passed by the caller as argument to gallivm_create()
. It will be a more invasive change, but it will be cleaner. And in
particular it will garantee t
On 29/07/14 16:31, Brian Paul wrote:
On 07/19/2014 09:16 AM, Paul wrote:
Brian Paul vmware.com> writes:
On 07/11/2014 01:47 AM, Florian Link wrote:
Hi everyone,
I read a post from 2012 that MESA supports geometry shaders. I tried a
current MESA 10.2.x release, but MESA GL_VERSION returns O
On 30/07/14 10:42, jfons...@vmware.com wrote:
From: José Fonseca
To prevent collision with wingdi.h's ERROR define, using the same _TOKEN
suffix already forsome other tokens due to similar reasons.
PS: Name collisions will be rife with single capitalized words. And
using _TOKEN suffix for onl
On 30/07/14 03:42, Kenneth Graunke wrote:
On Tuesday, July 29, 2014 05:02:39 PM Brian Paul wrote:
ERROR is a #define in the MSVC WinGDI.h header file.
Add the _TOKEN suffix as we do for a few other lexer tokens.
Brian, sorry I missed your review and ended up duplicating it byte per
byte! Ob
On 30/07/14 04:08, srol...@vmware.com wrote:
From: Roland Scheidegger
When using (d3d10) conformant out-of-bound behavior for texel fetching
(currently always enabled) the level still needs to be set to a safe value
even though the offset in the end won't get used because the level is used
to l
Series looks good to me too. Seems a nice cleanup.
Jose
From: srol...@vmware.com
Sent: 31 July 2014 19:26
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH 3/3] llvmpipe: don't store number of layers per level
Looks alright be me.
Jose
- Original Message -
> From: Kyle McMartin
>
> MCJIT is the only supported LLVM JIT on AArch64 and ARM (the regular
> JIT has bit-rotted badly on ARM and doesn't exist on AArch64.)
>
> Signed-off-by: Kyle McMartin
>
> --- a/src/gallium/auxiliary/gallivm/lp_b
Looks good AFAICT.
Just one detail:
s/false/FALSE/
s/true/TRUE/
Jose
- Original Message -
> From: Roland Scheidegger
>
> Instead of just ignoring the srgb/linear conversions, simply call the
> corresponding conversion functions, for all of pack/unpack/fetch,
> both for float and u
Series looks good to me.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Usually with fixed point renderbuffers clamping is done as part of
> conversion.
> However, since we blend in float format, we essentially skip all conversion
> steps pre-blend but since this is still a fi
Looks OK to me.
Jose
- Original Message -
> There are earlier returns for PIPE_FUNC_NEVER and PIPE_FUNC_ALWAYS. The
> switch value of 'func' cannot be either of those values.
>
> Fixes "Logically dead code" defects reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/galliu
- Original Message -
> So, about two months ago I had the insane idea to pick up Joakim
> Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
> with the goal to make it run StarCraft 2 so I could finally play at a
> reasonable frame rate ...
>
> With help from Joakim an
dehigh = (3 + bit_pos / 8) < 8 ? blksrc[3 +
> bit_pos / 8] : 0;
> + const unsigned char code = (acodelow >> (bit_pos & 0x7) |
> (acodehigh << (8 - (bit_pos & 0x7 & 0x7;
>
> if (code == 0)
> --
> 1.7.9.5
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Brian Paul has an early draft [1]. You should start from there.
Jose
[1] http://lists.freedesktop.org/archives/mesa-dev/2013-June/040171.html
- Original Message -
> Hi All,
>
> I've been stalking this list for a while now and I thought I'd finally make
> an attempt to contribute somethi
- Original Message -
> On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger
> wrote:
> > Am 23.07.2013 19:08, schrieb Andre Heider:
> >> For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
> >> supports these extensions, but the OS doesn't, issuing these insns will
> >
- Original Message -
> FYI, OpenGL 4.4, which was released yesterday, adds GL_MAP_PERSISTENT
> and GL_MAP_COHERENT bits as valid parameters of glMapBufferRange and
> glBufferStorage, allowing to use buffers for rendering while they are
> mapped and upload/download data to/from the buffers s
201 - 300 of 2351 matches
Mail list logo
