Re: [Mesa-dev] [PATCH] gallivm: Introduce lp_format_intrinsic.

ize, "%s.%c%u", name_root, c, width); > + } > +} > + > + > LLVMValueRef > lp_declare_intrinsic(LLVMModuleRef module, > const char *name, > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.h > b/src/

Re: [Mesa-dev] [PATCH 1/3] r600: Change default behaviour for undefined COLOR0

Am 03.04.2016 um 10:11 schrieb Axel Davy: > d3d 9 needs COLOR0 to be 1.0 on all channels when > undefined. 0.0 for the others is fine. > GL behaviour is undefined. > > Signed-off-by: Axel Davy > --- > src/gallium/drivers/r600/r600_state.c | 4 > 1 file changed, 4

Re: [Mesa-dev] [PATCH 2/3] gallivm: Prefer backend agnostic intrinsic for rounding.

} > + > + util_snprintf(intrinsic, sizeof intrinsic, "%s.v%uf%u", > +intrinsic_root, type.length, type.width); > + > + return lp_build_intrinsic_unary(builder, intrinsic, bld->vec_type, a); > + } > else /* (util_cpu_caps.has_altivec)

Re: [Mesa-dev] [PATCH 3/3] gallivm: Use llvm.fabs.

t; + util_snprintf(intrinsic, sizeof intrinsic, "llvm.fabs.v%uf%u", > type.length, type.width); > + return lp_build_intrinsic_unary(builder, intrinsic, vec_type, a); > } > > if(type.width*type.length == 128 && util_cpu_caps.has_ssse3) { > Looks like fabs was ne

Re: [Mesa-dev] [PATCH 4/6] gallium: add way for drivers to create fences without flushing

gestions if anyone has a better idea. But right > now this, plus maybe eventually ripping out the old way, seems like > the best plan. > > BR, > -R > > On Fri, Apr 1, 2016 at 8:03 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> I'll admit I'm not an expert on this but

Re: [Mesa-dev] [PATCH 1/2] gallivm: Use standard LLVMSetAlignment from LLVM 3.4 onwards.

Ah nice, I wasn't aware this would now work. For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 02.04.2016 um 16:13 schrieb Jose Fonseca: > Only provide a fallback for LLVM 3.3. > > One less dependency on LLVM C++ interface. > --- > src/gallium/auxil

Re: [Mesa-dev] [PATCH 4/6] gallium: add way for drivers to create fences without flushing

I'll admit I'm not an expert on this but I got a bad feeling on it. Do you really need another per-context fence_finish function? This looks to me like rather than improving the existing api, it throws another one at the same problem, which is to be sort of used in parallel making things confusing

Re: [Mesa-dev] [PATCH] gallivm: Use vector selects on LLVM 3.4+.

r llvm versions had tendencies to lower things to scalars when things weren't directly doable with vector operations...). Hopefully it works on non-x86 backends too but we can't test this, so I'd say we just wait for the bug reports ;-). Reviewed-by: Roland Scheidegger <srol...@vmware.com> _

Re: [Mesa-dev] [PATCH] tgsi: split tgsi_util_get_texture_coord_dim() function into two

nsigned num_coords = tgsi_util_get_texture_coord_dim(target, ); > + unsigned num_coords = tgsi_util_get_texture_coord_dim(target); > LLVMValueRef coords[4]; > LLVMValueRef tmp; > int chan; > @@ -3387,8 +3386,8 @@ static void tex_fetch_args( > unsigned target = inst->Texture.Texture; > LLVMValueRef coords[5], derivs[6]; > LLVMValueRef address[16]; > - int ref_pos; > - unsigned num_coords = tgsi_util_get_texture_coord_dim(target, _pos); > + unsigned num_coords = tgsi_util_get_texture_coord_dim(target); > + int ref_pos = tgsi_util_get_shadow_ref_src_index(target); > unsigned count = 0; > unsigned chan; > unsigned num_deriv_channels = 0; > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] compiler/glsl: invalidate float suffixes for glsl 1.10

Am 31.03.2016 um 04:17 schrieb Ian Romanick: > Arg. :( > > It turns out that shaders in the game PlaneShift use float suffixes in > GLSL 1.10 shaders... at least the version of the shaders in our private > shader-db repo do. Once some one check to make sure the game still does > this, we will

Re: [Mesa-dev] [PATCH 1/2] tgsi: collect texture sampler target info in tgsi_scan_shader()

Am 29.03.2016 um 22:39 schrieb Jose Fonseca: > On 29/03/16 21:22, Roland Scheidegger wrote: >> I actually think "is_tex" is a bit confusing (because there's lots of >> other parts in the code where we don't really distinguish between >> "texture" and

Re: [Mesa-dev] [PATCH 2/2] mesa: make _mesa_prepare_mipmap_level() static

l_context *ctx, > - struct gl_texture_object *texObj, GLuint level, > - GLsizei width, GLsizei height, GLsizei depth, > - GLsizei border, GLenum intFormat, mesa_format > format); > - > void >

Re: [Mesa-dev] [PATCH 1/2] tgsi: collect texture sampler target info in tgsi_scan_shader()

ally it actually meant there'd be a texture token but we have that with sample instructions as well...) Roland For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 29.03.2016 um 21:41 schrieb Brian Paul: > Texture sample instructions specify a sampler unit and texture t

Re: [Mesa-dev] [PATCH] xlib: add support for GLX_ARB_create_context

s/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h > index bd6e970..aff38f7 100644 > --- a/src/mesa/drivers/x11/glxapi.h > +++ b/src/mesa/drivers/x11/glxapi.h > @@ -201,6 +201,11 @@ struct _glxapi_table { > void (*BindTexImageEXT)(Display *dpy, GLXDrawable draw

Re: [Mesa-dev] [PATCH] tgsi: collect texture sampler target info in tgsi_scan_shader()

Am 29.03.2016 um 03:43 schrieb Brian Paul: > Texture sample instructions specify a sampler unit and texture target > such as "1D", "2D", "CUBE", etc. Sampler view declarations also specify > the sampler unit and texture target. > > This patch checks that the texture instructions agree with the

Re: [Mesa-dev] [PATCH 2/2] st/mesa: simplify st_generate_mipmap()

tLevel); > - } > - > - dstImage = _mesa_get_tex_image(ctx, texObj, target, dstLevel); > - if (!dstImage) { > - _mesa_error(ctx, GL_OUT_OF_MEMORY, "generating mipmaps"); > - return; > - } > - > - /* Free old image data */

Re: [Mesa-dev] tgsi_set_exec_mask?

Am 21.03.2016 um 03:08 schrieb Dave Airlie: > This appears to set some values into some temp register that we never > read from or look at again, > > should it be setting something that ExecMask gets set to at machine run time? > > just noticed it while trying to work out the various mask for

Re: [Mesa-dev] lvm pipe crash under windows

ry? > > Cheers > Jason > > On 17/03/2016 12:36 pm, "Jason Anderssen" <janders...@exactal.com> wrote: > >> Mesa version is 11.1.2 >> LVM - 3.4 >> Ill see what I can do regarding a gdb backtrace. >> >> Cheers >> Jason >> &g

Re: [Mesa-dev] Building Mesa and LLVM cross compiling Linux to Windows issue

I suspect you simply ran into an issue with old mesa and new llvm. Unfortunately some usage of the c++ abi of llvm is unavoidable, and the abi is unstable, thus breaking quite often. And we do not generally backport such fixes to older mesa releases (if only mostly because nobodoy would actually

Re: [Mesa-dev] lvm pipe crash under windows

Am 17.03.2016 um 01:52 schrieb Jason Anderssen: > Hi all, > > I was wondering if anyone knows of or has seen a crash when Mesa is > compiled for with LVM Pipe ? > The reason I ask is that if our user uses a compiled version of Mesa > using the slower software render, it works fine, the moment we

Re: [Mesa-dev] Best way to create a debug version of Mesa

Am 18.03.2016 um 03:20 schrieb Jason Anderssen: > Hi, > > This is probably a very simple question I hope, using scons, what is the > easiest way to create a debug build, the Doc on the website I think only > refers to Make-Config ? > I am also cross compiling for windows. > you control that

Re: [Mesa-dev] [PATCH] draw: fix line stippling

Am 15.03.2016 um 08:20 schrieb Jose Fonseca: > On 13/03/16 20:40, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> The logic was comparing actual ints, not true/false values. >> This meant that it was emitting always multiple line s

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

Am 15.03.2016 um 02:37 schrieb Stéphane Marchesin: > On Mon, Feb 1, 2016 at 8:14 AM, Brian Paul <bri...@vmware.com> wrote: >> On 01/31/2016 06:00 PM, srol...@vmware.com wrote: >>> >>> From: Roland Scheidegger <srol...@vmware.com> >>> >>> Wh

Re: [Mesa-dev] [PATCH 5/5] i965: Stop XY clipping point and line primitives.

Am 11.03.2016 um 03:50 schrieb Kenneth Graunke: > On Friday, March 11, 2016 2:50:46 AM PST Roland Scheidegger wrote: >> Technically, this is still wrong for rendering traditional gl points, >> which indeed require points either be drawn in full (even the parts >> outside vi

Re: [Mesa-dev] [PATCH 5/5] i965: Stop XY clipping point and line primitives.

Technically, this is still wrong for rendering traditional gl points, which indeed require points either be drawn in full (even the parts outside viewport, if the center is inside viewport) or not at all (if the center is outside viewport). Albeit the gles language may be different (and looks like

Re: [Mesa-dev] [PATCH] scons: build osmesa swrast and gallium

Am 10.03.2016 um 08:47 schrieb Andreas Fänger: > >> -Ursprüngliche Nachricht----- Von: Roland Scheidegger Gesendet: >> Mittwoch, 9. März 2016 17:31 Betreff: Re: [Mesa-dev] [PATCH] scons: >> build osmesa swrast and gallium >> >> Am 09.03.201

Re: [Mesa-dev] [GSoC2016] Interested in implementing "Soft" double precision floating point support

Am 09.03.2016 um 23:51 schrieb Ian Romanick: > On 03/09/2016 02:25 AM, tournier.elie wrote: >> Hi everyone. >> >> My name is Elie TOURNIER, I am enrolled in a French Engineering school >> (Telecom Physique Strasbourg) specialized in Medical ICT. >> I'm interested in implementing "Soft" double

Re: [Mesa-dev] [PATCH] scons: build osmesa swrast and gallium

Am 09.03.2016 um 08:41 schrieb Andreas Fänger: >> -Ursprüngliche Nachricht- Von: Roland Scheidegger Gesendet: >> Dienstag, 8. März 2016 18:26 Betreff: Re: [Mesa-dev] [PATCH] scons: >> build osmesa swrast and gallium >> >> Not that I really care what you c

Re: [Mesa-dev] [PATCH] scons: build osmesa swrast and gallium

Not that I really care what you can or can't build (and I won't comment on build changes), what are those features lacking in llvmpipe, beside from anisotropic filtering (which I always considered essentially useless for a software renderer, albeit interesting if you're curious about the math

Re: [Mesa-dev] [PATCH] gallium: fix PIPE_BIND_QUERY_BUFFER - PIPE_BIND_SCANOUT overlap

e PIPE_BIND_SHARED (1 << 20) /* get_texture_handle ??? */ > +#define PIPE_BIND_LINEAR (1 << 21) > > > /** > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

Am 01.03.2016 um 00:56 schrieb Rowley, Timothy O: > > On Feb 29, 2016, at 3:47 PM, Roland Scheidegger > <srol...@vmware.com<mailto:srol...@vmware.com>> wrote: > > Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O: Modest ping: > haven’t had any comments on these p

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O: > Modest ping: haven’t had any comments on these patches for a few > days. Patches look ok to me (for the parts I looked at and commented on). > I don’t have freedesktop git write privileges, so once the patches > are cleared it would be great if

Re: [Mesa-dev] [PATCH 1/2] i965/fs: fix precision of f2b

t;>>> On 02/25/2016 12:13 PM, Francisco Jerez wrote: >>>>> Ian Romanick <i...@freedesktop.org> writes: >>>>> >>>>>> On 02/25/2016 08:46 AM, Roland Scheidegger wrote: >>>>>>> Am 25.02.2016 um 11:15 schrieb Iago T

Re: [Mesa-dev] [PATCH 1/2] i965/fs: fix precision of f2b

Am 25.02.2016 um 11:15 schrieb Iago Toral Quiroga: > From the OpenGL 4.2 spec: > > "When a constructor is used to convert any integer or floating-point type to a > bool, 0 and 0.0 are converted to false, and non-zero values are converted to > true." > > Thus, even the smallest non-zero

Re: [Mesa-dev] [PATCH] gallium: remove duplicate define from enum pipe_format

8_UNORM > #define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_R8G8B8X8_UNORM > -#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM > #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM > #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM > #define PIPE_FORMAT_BGRA8

Re: [Mesa-dev] [PATCH] st/mesa: fix frontbuffer glReadPixels regressions

->_ColorReadBufferIndex == BUFFER_FRONT_RIGHT) && > + fb->Attachment[fb->_ColorReadBufferIndex].Type == GL_NONE) { > + /* add the buffer */ >st_manager_add_color_renderbuffer(st, fb, fb->_ColorReadBufferIndex); > + st_validate_state( st, ST_PIPEL

Re: [Mesa-dev] [PATCH] docs: Correct typo in LLVMpipe envvar description

Am 20.02.2016 um 13:28 schrieb Rhys Kidd: > On 13 February 2016 at 15:41, Rhys Kidd > wrote: > > Signed-off-by: Rhys Kidd > > --- > docs/envvars.html | 2 +- > 1 file changed, 1

Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit

Am 19.02.2016 um 11:57 schrieb Iago Toral: > On Thu, 2016-02-18 at 16:13 -0800, Ian Romanick wrote: >> On 02/18/2016 01:47 PM, Ian Romanick wrote: >>> On 02/18/2016 08:44 AM, Neil Roberts wrote: I made a pathological test case (attached) which repeatedly renders into an MSAA FBO and then

Re: [Mesa-dev] [PATCH 3/4] Mesa changes for adding OpenSWR

R > + if (strcmp(driver, "swr") == 0) { > + screen = swr_create_screen( winsys ); > + if (screen) > + use_swr = TRUE; > } > -#else > (void) driver; > #endif > > if (screen == NULL) { >screen = softpipe_create_scree

Re: [Mesa-dev] [PATCH 2/2] gallivm: Check whether to stop disassemble only for x86

1 && bytes[pc] == 0xc3) { > break; >} > +#endif > >/* > * Advance. > My c++ is a bit weak but the series looks good to me too. Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: add special case ubyte[4] / BGRA conversion function

Looks ok to me, albeit the sse2 code I posted a while ago for handling swizzled stores probably would be faster still (though only with x86 sse2...). At least I think it would hit this (if not the next patch in the series should...). Matt Turner reviewed the first 2 patches in the series (albeit I

Re: [Mesa-dev] [PATCH] llvmpipe: add a few const qualifiers

> 3) { >/* why not just use draw_regions */ > - struct u_rect *scissor = >scissors[viewport_index]; > + const struct u_rect *scissor = >scissors[viewport_index]; >struct lp_rast_plane *plane_s = [3]; >boolean s_planes[4]; >sc

Re: [Mesa-dev] [PATCH] st/mesa: fix pbo uploads

Am 18.02.2016 um 16:34 schrieb Ilia Mirkin: > On Feb 18, 2016 6:16 AM, "Marek Olšák" > wrote: >> >> On Thu, Feb 18, 2016 at 7:07 AM, Ilia Mirkin > wrote: >> > - LOD must be provided in .w for TXF

Re: [Mesa-dev] Introducing OpenSWR: High performance software rasterizer

Am 17.02.2016 um 22:09 schrieb Rowley, Timothy O: >> On Nov 18, 2015, at 12:34 PM, Emil Velikov >> wrote: I have no objections against >> getting this merged, although here are a couple of things that >> should be sorted. Some of these are just reiteration from others: >

Re: [Mesa-dev] [PATCH] st/mesa: apply DepthMode swizzle to stencil texturing as well

Am 17.02.2016 um 17:17 schrieb Ilia Mirkin: > On Wed, Feb 17, 2016 at 11:13 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 17.02.2016 um 14:43 schrieb Ilia Mirkin: >>> Gallium doesn't present these as GL_RED-style. A swizzle is necessary to >>> p

Re: [Mesa-dev] [PATCH] st/mesa: apply DepthMode swizzle to stencil texturing as well

Am 17.02.2016 um 14:43 schrieb Ilia Mirkin: > Gallium doesn't present these as GL_RED-style. A swizzle is necessary to > present the proper data in the unused components. > > Signed-off-by: Ilia Mirkin > --- > > The GL 4.5 compat spec also makes it clear that sampling from

Re: [Mesa-dev] [PATCH] st/mesa: use cso_set_viewport_dims() in try_pbo_upload_common()

;height, FALSE); > > /* Blend state */ > cso_set_blend(cso, >pbo_upload.blend); > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Handle removal of LLVMAddTargetData in SVN revision 260919

Am 16.02.2016 um 15:45 schrieb Matthew Dawson: > On Tuesday, February 16, 2016 4:19:49 PM EST Michel Dänzer wrote: >> On 16.02.2016 15:25, Matthew Dawson wrote: >>> LLVM removed LLVMAddTargetData for the 3.9 release in r260919. For the >>> two >>> places in mesa where this is called, only enable

Re: [Mesa-dev] [PATCH] mesa: move assertion in _mesa_cube_face_target()

e_face_target(GLenum target, unsigned face) > { > - assert(face < 6); > - if (target == GL_TEXTURE_CUBE_MAP) > + if (target == GL_TEXTURE_CUBE_MAP) { > + assert(face < 6); >return GL_TEXTURE_CUBE_MAP_POSITIVE_X + face; > - else > + } > + else { >

Re: [Mesa-dev] [PATCH v3 17/19] st/mesa: add compute program dispatch callbacks

Am 10.02.2016 um 19:10 schrieb Samuel Pitoiset: > This state tracker implements DispatchCompute() and DispatchComputeIndirect(). > > Signed-off-by: Samuel Pitoiset > Reviewed-by: Marek Olšák > Reviewed-by: Ilia Mirkin > ---

Re: [Mesa-dev] [PATCH v3 17/19] st/mesa: add compute program dispatch callbacks

Am 13.02.2016 um 16:56 schrieb Samuel Pitoiset: > > > On 02/13/2016 04:52 PM, Roland Scheidegger wrote: >> Am 10.02.2016 um 19:10 schrieb Samuel Pitoiset: >>> This state tracker implements DispatchCompute() and >>> DispatchComputeIndirect(). >>> >&g

Re: [Mesa-dev] [PATCH] st/mesa: fix pipe_grid_info initializer

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 13.02.2016 um 17:02 schrieb Samuel Pitoiset: > Fixes MSVC build error which doesn't allow empty initializers. > > Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> > Cc: Roland Scheidegger <srol...@vm

Re: [Mesa-dev] [PATCH 1/5] mesa: remove _ARB suffix from cube map enums

> - case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB: > - case GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB: > - case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB: > + case GL_TEXTURE_CUBE_MAP_POSITIVE_X: > + case GL_TEXTURE_CUBE_MAP_NEGATIVE_X: > + case GL_TEXTURE_CUBE_MAP_POSITIVE_Y: > + case GL_TE

Re: [Mesa-dev] [PATCH] mesa: Fix test for big-endian architecture in compiler.h

Am 12.02.2016 um 10:01 schrieb Jochen Rollwagen: > Hi, > > i think i found & fixed a bug in mesa concerning tests for big-endian > machines. The defines tested don't exist or are wrongly defined so the > test (probably) never fires. The gcc defines on my machine concerning > big-endian are > >

Re: [Mesa-dev] [PATCH 1/3] configure: Eliminate MSVC2008 compatibility.

MPAT_CFLAGS) > > noinst_LTLIBRARIES = libtrace.la > > diff --git a/src/util/Makefile.am b/src/util/Makefile.am > index e05a2c5..0935891 100644 > --- a/src/util/Makefile.am > +++ b/src/util/Makefile.am > @@ -38,7 +38,7 @@ libmesautil_la_CPPFLAGS = \ > -I$(top_srcdir)/src/gallium/auxiliary \ > $(SHA1_CFLAGS) \ > $(VISIBILITY_CFLAGS) \ > - $(MSVC2008_COMPAT_CFLAGS) > + $(MSVC2013_COMPAT_CFLAGS) > > libmesautil_la_SOURCES = \ > $(MESA_UTIL_FILES) \ > For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] building with -Wshadow

Am 10.02.2016 um 05:43 schrieb Dave Airlie: > I was just messing with warning flags on virglrenderer and noticed > -Wshadow generated a fair few warnings with gallium, so I did a mesa > build with -Wshadow enabled and it was fairly messy, > > do we care? there could be bugs hiding in -Wshadow

Re: [Mesa-dev] [PATCH] llvmpipe: Do not use barriers if not using threads.

t; + pipe_barrier_destroy( >barrier ); > + } > > lp_scene_queue_destroy(rast->full_scenes); > > Oh good find. I am wondering why it worked before - barriers with 0 count were never legal, and it looks like the glibc implementation would always have returned an

Re: [Mesa-dev] [PATCH] mesa: fix incorrect viewport position when GL_CLIP_ORIGIN = GL_LOWER_LEFT

} > + translate[1] = half_height + y; > + > if (ctx->Transform.ClipDepthMode == GL_NEGATIVE_ONE_TO_ONE) { >scale[2] = 0.5 * (f - n); >translate[2] = 0.5 * (n + f); > With the caveat that I always get confused by

Re: [Mesa-dev] [PATCH 3/3] st/mesa: clarify some texture target code in st_cb_drawpix.c

normalized = sv[0]->texture->target != PIPE_TEXTURE_RECT; > + boolean normalized = sv[0]->texture->target == PIPE_TEXTURE_2D; > + > + assert(sv[0]->texture->target == st->internal_target); > > /* limit checks */ > /* XXX if DrawPixels image is larger than ma

Re: [Mesa-dev] [RFCv3 11/11] mesa/st: add support for NIR as possible driver IR

Am 06.02.2016 um 22:30 schrieb Marek Olšák: > On Sat, Feb 6, 2016 at 2:45 PM, Rob Clark wrote: >> On Sun, Jan 31, 2016 at 3:16 PM, Rob Clark wrote: >>> + // XXX get from pipe_screen? Or just let pipe driver provide? >>> + nir_options.lower_fpow =

Re: [Mesa-dev] [PATCH] radeonsi: enable denorms for 64-bit and 16-bit floats

This looks good to me, albeit I know nothing about the hw. So VI could do (just with some restrictios) even full-speed fp32 denorms whereas SI/CI can't? Interesting, I suppose that would be intended for compute. intel x86 can't even do that (actually, I think skylake can), though certainly other

Re: [Mesa-dev] [RFCv3 11/11] mesa/st: add support for NIR as possible driver IR

Am 08.02.2016 um 14:59 schrieb Rob Clark: > On Mon, Feb 8, 2016 at 6:58 AM, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 06.02.2016 um 22:30 schrieb Marek Olšák: >>> On Sat, Feb 6, 2016 at 2:45 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>>

Re: [Mesa-dev] [PATCH] radeonsi: enable denorms for 64-bit and 16-bit floats

Am 09.02.2016 um 00:53 schrieb Ian Romanick: > On 02/08/2016 03:37 PM, Roland Scheidegger wrote: >> Am 09.02.2016 um 00:02 schrieb Ian Romanick: >>> On 02/08/2016 12:38 PM, Marek Olšák wrote: >>>> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard <t...@stellard.net&g

Re: [Mesa-dev] [PATCH] radeonsi: enable denorms for 64-bit and 16-bit floats

Am 09.02.2016 um 00:02 schrieb Ian Romanick: > On 02/08/2016 12:38 PM, Marek Olšák wrote: >> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote: >>> On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote: From: Marek Olšák This fixes

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 15:44 schrieb Marek Olšák: > On Fri, Feb 5, 2016 at 10:57 AM, Marek Olšák wrote: >> On Fri, Feb 5, 2016 at 1:55 AM, Matt Turner wrote: >>> On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák wrote: From: Marek Olšák

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 16:08 schrieb Marek Olšák: > On Fri, Feb 5, 2016 at 3:56 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 05.02.2016 um 15:44 schrieb Marek Olšák: >>> On Fri, Feb 5, 2016 at 10:57 AM, Marek Olšák <mar...@gmail.com> wrote: >>>> O

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 17:04 schrieb Marek Olšák: > On Fri, Feb 5, 2016 at 4:48 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 05.02.2016 um 16:08 schrieb Marek Olšák: >>> On Fri, Feb 5, 2016 at 3:56 PM, Roland Scheidegger <srol...@vmware.com> >>> wro

Re: [Mesa-dev] [PATCH] Add (un)packHalf tests which don't fail on GCN

Would probably make more sense on the piglit ml... That said, the existing unpack works on llvmpipe just fine even if you enable that half cap bit (unpack is always exact). The only potential gotcha I see is with denorms - the result of course is never a fp32 denorm but I suppose depending on your

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 01:55 schrieb Matt Turner: > On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák wrote: >> From: Marek Olšák >> >> This is a subset of the generated tests which are known to fail >> on everything except CPU emulation (AFAIK). >> --- > > This is

Re: [Mesa-dev] [PATCH] mesa: Use SSE prefetch instructions rather than 3DNow instructions

why not.) Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 03.02.2016 um 22:05 schrieb Timothy Arceri: > From: Patrick Baggett <baggett.patr...@gmail.com> > > 64-bit Pentium 4 CPUs don't have the 3DNow prefetch instructions > which results in an Illegal instructio

Re: [Mesa-dev] [PATCH 2/3] radeonsi: implement PK2H and UP2H opcodes

Am 03.02.2016 um 10:38 schrieb Michel Dänzer: > On 03.02.2016 18:29, Marek Olšák wrote: >> On Wed, Feb 3, 2016 at 10:19 AM, Michel Dänzer wrote: >>> On 03.02.2016 05:15, Marek Olšák wrote: On Sat, Jan 30, 2016 at 12:46 AM, Marek Olšák wrote: > From:

Re: [Mesa-dev] [PATCH 2/3] radeonsi: implement PK2H and UP2H opcodes

Am 03.02.2016 um 18:01 schrieb Marek Olšák: > On Wed, Feb 3, 2016 at 5:37 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 03.02.2016 um 10:38 schrieb Michel Dänzer: >>> On 03.02.2016 18:29, Marek Olšák wrote: >>>> On Wed, Feb 3, 2016 at 10:19 AM, Mich

Re: [Mesa-dev] [PATCH 2/3] radeonsi: implement PK2H and UP2H opcodes

Am 03.02.2016 um 18:29 schrieb Roland Scheidegger: > Am 03.02.2016 um 18:01 schrieb Marek Olšák: >> On Wed, Feb 3, 2016 at 5:37 PM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> Am 03.02.2016 um 10:38 schrieb Michel Dänzer: >>>> On 03.02.2016 18:

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: drop scissor planes early if the tri is fully inside them

Am 02.02.2016 um 13:32 schrieb Jose Fonseca: > On 01/02/16 01:00, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> If the tri is fully inside a scissor edge (or rather, we just use the >> bounding box of the tri for

Re: [Mesa-dev] [PATCH 2/5] mesa: implement GL_NVX_gpu_memory_info

Am 02.02.2016 um 20:41 schrieb Marek Olšák: > On Tue, Feb 2, 2016 at 4:02 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> Does anyone use these extensions? >> I suppose maybe to get the total amount of video memory? >> From the dynamic counts, I would have tho

Re: [Mesa-dev] [PATCH 2/3] radeonsi: implement PK2H and UP2H opcodes

Am 02.02.2016 um 21:15 schrieb Marek Olšák: > On Sat, Jan 30, 2016 at 12:46 AM, Marek Olšák wrote: >> From: Marek Olšák >> >> Based on a gallivm patch by Ilia Mirkin. >> >> +8 piglit regressions due to precision issues >> --- >>

Re: [Mesa-dev] [PATCH 2/5] mesa: implement GL_NVX_gpu_memory_info

Does anyone use these extensions? I suppose maybe to get the total amount of video memory? From the dynamic counts, I would have thought the eviction one would be the most interesting, but this one isn't implemented. Ah well I guess a sloppily implemented extension is better than none. Roland Am

Re: [Mesa-dev] [PATCH 2/4] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

gig92I2slinye-TToGAmNP8dl5F9AsSX4ehA=uowtFMWBy9fKM5iN6ZsSGHoOLkYskpAvf4coEYs3ESg= > > > > /Marta > >> -Original Message- >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On >> Behalf Of Roland Scheidegger >> Sent: Friday, January 29, 2016 2:18

Re: [Mesa-dev] [PATCH 2/2] gallivm: add PK2H/UP2H support

Am 02.02.2016 um 13:39 schrieb Jose Fonseca: > On 31/01/16 02:08, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> Add support for these opcodes, the conversion functions were already >> there albeit need some new packing stuff. >

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: drop scissor planes early if the tri is fully inside them

Am 01.02.2016 um 17:14 schrieb Brian Paul: > On 01/31/2016 06:00 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> If the tri is fully inside a scissor edge (or rather, we just use the >> bounding box of the tri for

Re: [Mesa-dev] [PATCH 1/2] tgsi: add PK2H/UP2H support

argets, clear colors, this shader opcode). >> Hence for now don't enable the cap bit (so the code is unused). >> (Code is from imirkin, comment from sroland) > > Minor code nit-picks below. > > Otherwise, > Reviewed-by: Brian Paul <bri...@vmware.com> > > &

Re: [Mesa-dev] [PATCH 2/2] gallivm: add PK2H/UP2H support

Am 01.02.2016 um 16:36 schrieb Brian Paul: > Just a few more nitpicks below... > > Reviewed-by: Brian Paul <bri...@vmware.com> > > On 01/30/2016 07:08 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> Add support for

Re: [Mesa-dev] [RFCv3 00/11] gallium: add support for NIR as alternate IR

For the first 2 in the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 31.01.2016 um 21:16 schrieb Rob Clark: > From: Rob Clark <robcl...@freedesktop.org> > > Ok, v3 of something I've been working on here and there for a while.. > > Since the last t

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: drop scissor planes early if the tri is fully inside them

Am 01.02.2016 um 02:00 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > If the tri is fully inside a scissor edge (or rather, we just use the > bounding box of the tri for the comparison), then we can drop these > additional scissor "pla

Re: [Mesa-dev] [PATCH 1/3] gallivm: don't crash on UP2H and set correct src type

ODE_SAMPLE_I_MS: > case TGSI_OPCODE_UMUL_HI: > + case TGSI_OPCODE_UP2H: >return TGSI_TYPE_UNSIGNED; > case TGSI_OPCODE_IMUL_HI: > case TGSI_OPCODE_I2F: > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

Am 29.01.2016 um 00:31 schrieb Matt Turner: > On Sun, Jan 17, 2016 at 1:49 PM, <srol...@vmware.com> wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> The existing code used ssse3, and because it isn't compiled in a separate >> file com

Re: [Mesa-dev] [PATCH] appveyor: Bump shallow clone depth.

c_I=Gk3CFJ05oqh1znZSK1leG9LvG7wkREWxQVsngYqVz1I=wFvmNDxxHy03-JtSUUpyCLwXuXnfEH-YGa90ke-LrXw= > > +clone_depth: 100 > > cache: > - win_flex_bison-2.4.5.zip > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 01/11] tgsi: add MEMBAR opcode to handle memoryBarrier* GLSL intrinsics

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 24.01.2016 um 19:59 schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> > Reviewed-by: Marek Olšák <marek.ol...@amd.com> (v1) > > v1 -> v2: add defines for the various bits &g

Re: [Mesa-dev] [PATCH 2/4] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

Ping? Am 17.01.2016 um 22:49 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > The existing code used ssse3, and because it isn't compiled in a separate > file compiled with that, it is usually not used (that, of course, could > be fixed...), w

Re: [Mesa-dev] [PATCH v2 01/10] tgsi: add MEMBAR opcode to handle memoryBarrier* GLSL intrinsics

OPCODE_BARRIER?). Anyway, I don't have any objections to this. Roland > > On Tue, Jan 19, 2016 at 12:04 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> I am actually wondering how well that would work for d3d11. >> d3d11 just has AllMemoryBarrier, DeviceMemoryBa

Re: [Mesa-dev] [PATCH] gallium: make image views non-persistent objects

FWIW why exactly are pipe_sampler_view and pipe_surface ref counted? These are all the same too from a high level perspective. I guess though there'd be significant effort to change that... Roland Am 19.01.2016 um 04:08 schrieb Ilia Mirkin: > Make them akin to shader buffers, with no

Re: [Mesa-dev] [PATCH v2 01/10] tgsi: add MEMBAR opcode to handle memoryBarrier* GLSL intrinsics

I am actually wondering how well that would work for d3d11. d3d11 just has AllMemoryBarrier, DeviceMemoryBarrier plus GroupMemoryBarrier - and for each of them also a "WithGroupSync" version. Hmm. Roland Am 19.01.2016 um 03:30 schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin

Re: [Mesa-dev] [PATCH] llvmpipe: fix arguments order given to vec_andc

y_neg_mask, dcdy), > + eo = vec_sub_epi32(vec_andnot_si128(dcdy_neg_mask, dcdy), > vec_and(dcdx_neg_mask, dcdx)); > >/* ei = _mm_sub_epi32(_mm_sub_epi32(dcdy, dcdx), eo); */ > Reviewed-by: Roland Scheidegger <srol...@vmware.com>

Re: [Mesa-dev] [PATCH] avoid crashing in mod by 0 with llvmpipe

) > + emit_data->output[emit_data->chan] = LLVMBuildOr(builder, > +div_mask, > +result, ""); > } > > /* TGSI_OPCODE_NOT */ > static void > not_emit_cpu( > const struct lp_build_tgsi_a

Re: [Mesa-dev] [PATCH] avoid crashing in mod by 0 with llvmpipe

Ok, pushed. Roland Am 15.01.2016 um 21:01 schrieb Jeff Muizelaar: > Do you mind fixing up the language to match what you're looking for > and committing it? > > Thanks, > > -Jeff > > On Fri, Jan 15, 2016 at 3:00 PM, Roland Scheidegger <srol...@vmware.com> >

Re: [Mesa-dev] [PATCH] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

There's actually a small bug in it, the argument order to _mm_andnot_si128 is swapped. Otherwise it should be ok... Roland Am 16.01.2016 um 03:58 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > The existing code used ssse3, and because it

Re: [Mesa-dev] [PATCH] st/mesa: use surface format to generate mipmaps when available

Looks good to me. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 14.01.2016 um 19:46 schrieb Ilia Mirkin: > This fixes the recently posted mipmap + texture views piglit test. > > Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> > Cc: "11.0 11.1"

Re: [Mesa-dev] [PATCH] gallivm: merge two identical LLVM version checks

ndif > -#if HAVE_LLVM >= 0x0304 > MAttrs.push_back(util_cpu_caps.has_sse4_2 ? "+sse4.2" : "-sse4.2"); > #else > + MAttrs.push_back(util_cpu_caps.has_sse4_1 ? "+sse41" : "-sse41" ); > MAttrs.push_back(util_cpu_caps.has_sse4_2 ? "

Re: [Mesa-dev] [PATCH 1/2] nir: Add a fquantize2f16 opcode

Am 13.01.2016 um 02:23 schrieb Jason Ekstrand: > On Tue, Jan 12, 2016 at 4:50 PM, Ian Romanick > wrote: > > With the SPIR-V link added and the wording change suggested by Erik RE: > precision vs. number of bits in the type, this series

Re: [Mesa-dev] [PATCH v3 1/3] gallium/st: add pipe_context::generate_mipmap()

rate_mipmap(struct gl_context *ctx, GLenum > target, >last_layer = util_max_layer(pt, baseLevel); > } > > - /* Try to generate the mipmap by rendering/texturing. If that fails, > -* use the software fallback. > + /* First see if the driver supports

<    4   5   6   7   8   9   10   11   12   13   >