Am 11.06.2013 02:41, schrieb Marek Olšák:
> On Mon, Jun 10, 2013 at 3:25 PM, Grigori Goronzy wrote:
>> Allows MSAA colorbuffers, which have a CMASK automatically and don't
>> need any further special handling, to be fast cleared. Instead
>> of clearing the buffer, set the clear color and the CMASK
Am 10.06.2013 16:31, schrieb Zack Rusin:
> Draw depended on clip_plane_enable being set in the rasterizer
> to use clipdistance registers for clipping. That's really
> unfriendly because it requires that rasterizer state to have
> variants for every shader out there. Instead of depending on
> the r
Am 10.06.2013 16:31, schrieb Zack Rusin:
> We need to figure out the number of invocations of the clipper
> before the emit, because in the emit we are after clipping
> where the number of primitives will be equal to number of clipper
> invocations minus the clipped primitives. So our computations
Am 10.06.2013 16:31, schrieb Zack Rusin:
> cull distance is analogous to clip distance. If a register is
> given this semantic, then the values in it are assumed to be a
> float32 distance to a plane. Primitives will be completely
> discarded if the plane distance for all of the vertices in
> the p
Am 10.06.2013 16:31, schrieb Zack Rusin:
> Works similarly to clip distance. If the cull distance is negative
> for all vertices against a specific plane then the primitive
> is culled.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_context.c | 17
> src/galli
Am 11.06.2013 05:39, schrieb Zack Rusin:
> There are strict limits on those registers. Define the maximums
> and use them instead of magic numbers. Also allows us to add
> some extra sanity checks.
> Suggested by Brian.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_contex
gs->shader.tokens) {
>/* we have an empty geometry shader with stream output, so
> @@ -135,7 +135,7 @@ softpipe_draw_vbo(struct pipe_context *pipe,
>draw_set_indexes(draw, NULL, 0, 0);
> }
>
> - draw_set_mapped_so_targets(draw, 0, NULL);
> + draw_set_mapped_so_targets(draw, 0, NULL, 0);
>
> /*
> * TODO: Flush only when a user vertex/index buffer is present
> diff --git a/src/gallium/drivers/softpipe/sp_state_so.c
> b/src/gallium/drivers/softpipe/sp_state_so.c
> index 3682c6c..96bb6b1 100644
> --- a/src/gallium/drivers/softpipe/sp_state_so.c
> +++ b/src/gallium/drivers/softpipe/sp_state_so.c
> @@ -77,6 +77,7 @@ softpipe_set_so_targets(struct pipe_context *pipe,
> }
>
> softpipe->num_so_targets = num_targets;
> + softpipe->so_append_bitmask = append_bitmask;
> }
>
> void
>
Reviewed-by: Roland Scheidegger
Though I find stream output very confusing...
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 14.06.2013 19:49, schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> For conditional rendering this makes it possible to skip rendering
> if either the predicate is true or false, as supported by d3d10
> (in fact previously it was sort of implied skip rendering if predi
Am 25.03.2013 16:19, schrieb Richard Sandiford:
> The AoS version of ld_build_blend_factor was assuming that if the first
> channel was alpha, there were no rgb components.
>
> Fixes several piglit tests on System z. No piglit regressions on x86_64.
> The shortcut is still used in tests like spec
Am 19.06.2013 18:39, schrieb Brian Paul:
> ---
> src/gallium/drivers/svga/svga_tgsi.c | 128
> +-
> 1 file changed, 65 insertions(+), 63 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_tgsi.c
> b/src/gallium/drivers/svga/svga_tgsi.c
> index 8bea7f8..
there's
> + * different front/back fill modes, that can be handled with the
> + * 'draw' module.
> + */
> int u_unfilled_generator( unsigned prim,
>unsigned start,
>unsigned nr,
>
For the series:
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 22.06.2013 00:26, schrieb Brian Paul:
> It should never be zero and for cube/cube_arrays it should be a
> multiple of six.
> ---
> src/gallium/docs/source/resources.rst |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/docs/source/resources.rst
> b/src/gallium/docs
before/after all occurences of
> resource_copy_region and blit would be prone to regressions and it
> would also need much more work.
>
> Marek
>
>
> On Sat, Jun 15, 2013 at 12:01 AM, Roland Scheidegger
> wrote:
>> Am 14.06.2013 19:49, schrieb srol...@vmwar
the buffers is too small to do any valid drawing */
> - debug_warning("draw: VBO too small to draw anything\n");
> - return;
> + debug_warning("draw: VBO too small to draw anything\n");
> + return;
> + }
>
Am 27.06.2013 09:48, schrieb Jose Fonseca:
> - Original Message -
>> From: Roland Scheidegger
>>
>> If there are queries active the opaque optimization reseting the bin needs to
>> be disabled.
>> (Not really tested since the bug was discovered by code
Am 27.06.2013 09:41, schrieb Jose Fonseca:
> - Original Message -
>> From: Roland Scheidegger
>>
>> This was just ignored (unless for some reason like unfilled polys draw was
>> handling this).
>
> Patch looks good.
>
>> I'm not convinced o
Am 27.06.2013 14:51, schrieb Roland Scheidegger:
> Am 27.06.2013 09:48, schrieb Jose Fonseca:
>> - Original Message -
>>> From: Roland Scheidegger
>>>
>>> If there are queries active the opaque optimization reseting the bin needs
>>> to
>
Am 30.06.2013 03:02, schrieb Ilia Mirkin:
> Well, as luck would have it, I've redone it as SSE2 and it's faster
> (more instructions, but fewer cycles). So I'm just going to replace it
> with SSE2, which is on by default for x86_64. I didn't see any runtime
> feature detection logic in gallium, onl
->uint_bld.vec_type);
> + res = LLVMBuildBitCast(builder, res, bld_base->uint_bld.vec_type, "");
> } else if (stype == TGSI_TYPE_SIGNED) {
> - res = LLVMConstBitCast(res, bld_base->int_bld.vec_type);
> + res = LLVMBuildBitCast(builder, res, bl
Am 03.07.2013 17:28, schrieb Jose Fonseca:
> I don't fully grasp every detail (many paths), but looks good in principle.
>
> Where do the 16xf32 vectors come from?
Those are the size vectors. Normally (except for 1d case) these contain
width/height/depth/_ (or just width/height for 2d texture).
So
Am 03.07.2013 07:42, schrieb Zack Rusin:
> The semantics for overflow detection are a bit tricky with
> indexed rendering. If the base index in the elements array
> overflows, then the index of the first element should be used,
> if the index with bias overflows then it should be treated
> like a n
base->uint_bld, pipe_func,
> emit_data->args[0], emit_data->args[1]);
> - emit_data->output[emit_data->chan] = lp_build_select(&bld_base->uint_bld,
> - cond,
> -
Am 09.07.2013 07:18, schrieb Zack Rusin:
> the spec is very explicit about treatment of denorm floats and
> the behavior is exactly the same for them as it would be for -0 or
> +0. This makes our shading code match that behavior.
I think this warrants some closer mentioning of what spec this refers
fetch_source(mach, &src[1], &inst->Src[1], TGSI_CHAN_Y, src_datatype);
> + fetch_source(mach, &src[1], &inst->Src[1], TGSI_CHAN_X, src_datatype);
> op(&dst, &src[0], &src[1]);
> for (chan = 0; chan < TGSI_NUM_C
I don't quite understand what this should do, at first sight it looks
like a ugly hack (which should really not be part of gallium interface)
to make fast color clearing work better with window framebuffers.
Seems to go against the idea of resources (which are immutable, well not
the contents but t
Am 11.07.2013 16:13, schrieb Brian Paul:
> Just minor things below.
Ok, I'll fix this (and the things Jose mentioned).
>
> Reviewed-by: Brian Paul
>
> On 07/10/2013 06:21 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> We had to disab
Am 11.07.2013 15:50, schrieb Jose Fonseca:
>
>
> - Original Message -
>> From: Roland Scheidegger
>>
>> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
>> good enough. Reverse is using some rational polynomials and is quite
Am 11.07.2013 18:18, schrieb Zack Rusin:
> GLSL spec says that rsq is undefined for src<=0, but the D3D10
> spec says it needs to be a NaN, so lets stop taking an absolute
> value of the source which completely breaks that behavior.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/gal
Am 11.07.2013 18:54, schrieb Jose Fonseca:
> - Original Message -
>> From: Roland Scheidegger
>>
>> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
>> good enough. Reverse is using some rational polynomials and is quite
>> ac
interface stuff. If it is though I don't
like the name, and it also would need documentation.
Roland
>
> This commit only fixes r600g for st/dri. Any other co-state tracker
> (like st/egl and st/xlib) will be broken if it's used with r600g. I
> think we can ignore st/xlib
Am 11.07.2013 19:41, schrieb Jose Fonseca:
>>> Please use lp_build_polynomial. It tries to avoid data dependency.
>>> Furthermore, if we start using FMA, then it's less one place to update.
>> Ok. Are you sure it's worth avoiding data dependency at the cost of extra
>> instructions (the way I built
GSI_OPCODE_RSQ;
> case OPCODE_SCS:
>return TGSI_OPCODE_SCS;
> case OPCODE_SEQ:
> @@ -755,6 +753,14 @@ compile_instruction(
>emit_ddy( t, dst[0], &inst->SrcReg[0] );
>break;
>
> + case OPCODE_RSQ: {
> + struct ureg_dst temp = ureg_DEC
softpipe has tile caches though (for textures and render targets). I'm
not sure if they'd be flushed whenever needed or if that would even be a
problem.
As for llvmpipe, there's no caches there, I'm not sure if there could be
other problems.
Roland
Am 31.01.2014 00:44, schrieb Marek Olšák:
> I gu
Am 04.02.2014 13:19, schrieb Marek Olšák:
> On Tue, Feb 4, 2014 at 10:29 AM, Rogovin, Kevin
> wrote:
>>
>>
>>> I don't believe our hardware can support GL_ARB_shader_stencil_export.
>>> The render target write message can take RGBA, depth, and sample masks,
>>> but not stencil. Without that, it'
Am 04.02.2014 03:43, schrieb Zack Rusin:
> The number of allowed temporaries increases almost with every
> iteration of an api. We used to support 128, then we started
> increasing and the newer api's support 4096+. So if we notice
> that the number of temporaries is larger than our statically
> al
Am 05.02.2014 01:34, schrieb Zack Rusin:
> ureg_program is allocated on the heap so we can just bump the
> number of immediates that it can handle. It's needed for d3d10.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
I don't think that will actually work as then the new code will never
get used and we will always have a huge static array.
There doesn't seem to be an explicit limit for immediates we could use -
there's one in patch 3/3 but that's only a ureg limit. Maybe need a new
limit somewhere.
Roland
Am
Sorry just saw your other answers so you can forget this.
Roland
Am 05.02.2014 19:19, schrieb Roland Scheidegger:
> I don't think that will actually work as then the new code will never
> get used and we will always have a huge static array.
> There doesn't seem to be an
Am 05.02.2014 22:58, schrieb Grigori Goronzy:
> ---
> src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
> src/gallium/drivers/i915/i915_screen.c | 5 +
> src/gallium/drivers/ilo/ilo_screen.c | 3 +++
> src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
>
Am 06.02.2014 00:49, schrieb Jose Fonseca:
> I hadn't looked at GL_ARB_buffer_storage. I need to read more closely, but at
> a glance i looks like GL_MAP_PERSISTENT_BIT alone is okay (app needs to call
> FlushMappedBufferRange must be called to guarantee coherence) but if
> GL_MAP_COHERENCE_BIT
Am 06.02.2014 12:42, schrieb Marek Olšák:
> On Thu, Feb 6, 2014 at 2:40 AM, Roland Scheidegger wrote:
>> I don't think that would work. The reason for this stuff to exist is
>> because new hw makes that possible on the hw level directly.
>
> I don't think t
Am 07.02.2014 02:56, schrieb Ilia Mirkin:
> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This just adds the TG4 opcode, and a CAP for the
>> max texture gather components.
>
> Is this different from GATHER4? If it is, should probably be
> documented in docs/sourc
Am 07.02.2014 04:37, schrieb Dave Airlie:
> On Fri, Feb 7, 2014 at 12:36 PM, Roland Scheidegger
> wrote:
>> Am 07.02.2014 02:56, schrieb Ilia Mirkin:
>>> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote:
>>>> From: Dave Airlie
>>>>
>>
> ubyte *map = NULL;
> boolean done = FALSE;
>
> - if (!st->prefer_blit_based_texture_transfer) {
> + if (!st->prefer_blit_based_texture_transfer &&
> + !_mesa_is_format_compressed(texImage->TexFormat)) {
> + /* Try to avoid the fallback if we'
Am 07.02.2014 23:25, schrieb Dave Airlie:
>>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away
>>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should
>>> do.
>>>
>>> So I've reposted with the component selection in src1 now.
>>
>> Hmm seems a bit
Am 11.02.2014 02:43, schrieb Dave Airlie:
> From: Dave Airlie
>
> This adds support to gallium for a TG4 instruction,
> and two CAPs. The first CAP is required for GL_ARB_texture_gather.
>
> The second CAP is required to expose GL_ARB_gpu_shader5.
>
> However so far we haven't found any hardwar
Am 11.02.2014 22:58, schrieb Dave Airlie:
>>>dst.z = texture_depth(unit, lod)
>>>
>>> +.. opcode:: TG4 - Texture Gather (as per ARB_texture_gather)
>>> + Gathers the four texels to be used in a bi-linear
>>> + filtering operation and packs them into a single register
Hmm that reminds me when I implemented layered rendering in llvmpipe I
figured we'd only need to store the min amount of layers, because
rendering is undefined if the index is higher anyway. But of course I
didn't think about clears so we can't do that now correctly. Ah well if
anyone would really
Am 14.02.2014 18:07, schrieb Jeff Muizelaar:
> In doing some testing we’ve noticed that trying to draw pixel aligned
> textures does not work very well with linear filtering in llvmpipe.
>
> Here’s an example of the problem.
>
> Imagine wanting to paint a 100x100 texture. After being scaled by 10
Am 14.02.2014 19:59, schrieb Jeff Muizelaar:
>
> On Feb 14, 2014, at 1:00 PM, Roland Scheidegger <mailto:srol...@vmware.com>> wrote:
>
>> Am 14.02.2014 18:07, schrieb Jeff Muizelaar:
>>
>> I'll need to take another look and run some test
Am 14.02.2014 23:35, schrieb Roland Scheidegger:
> Am 14.02.2014 19:59, schrieb Jeff Muizelaar:
>>
>> On Feb 14, 2014, at 1:00 PM, Roland Scheidegger > <mailto:srol...@vmware.com>> wrote:
>>
>>> Am 14.02.2014 18:07, schrieb Jeff Muizelaar:
>>>
&g
FWIW I've just cleaned 1/3 and 3/3 up a little and splitted it off into
two patches (I really want to be able to track any changes this might
cause separately), and on x86 sse I actually managed to shave off one
instruction by using lp_build_iround() too :-).
2/3 is more of the same just for the ne
Am 15.02.2014 01:54, schrieb srol...@vmware.com:
> From: Jeff Muizelaar
>
> The previous method for converting coords to ints was sligthly inaccurate
> (effectively losing 1bit from the 8bit lerp weight). This is probably
> especially noticeable when trying to draw a pixel-aligned texture.
> As a
Am 19.02.2014 11:04, schrieb Kenneth Graunke:
> According to the "Point Multisample Rasterization" of the OpenGL
> specification (3.0 or later), smooth points are supposed to be enabled
> implicitly when multisampling, regardless of the GL_POINT_SMOOTH flag.
>
> However, if GL_POINT_SPRITE is enab
Am 22.02.2014 04:04, schrieb Emil Velikov:
> According to the GLX_MESA_query_renderer spec each driver should
> be able to report the version of each GL api they support before
> creating a context.
>
> Currently both classic mesa and gallium evaluate the version post
> context creation and while
Am 22.02.2014 04:04, schrieb Emil Velikov:
> Namely vendor/device id, accelerated and UMA, which will be used to describe
> the underlying renderer.
>
> Signed-off-by: Emil Velikov
> ---
> src/gallium/docs/source/screen.rst | 8
> src/gallium/include/pipe/p_defines.h | 5 +
> 2 fi
Am 22.02.2014 04:04, schrieb Emil Velikov:
> Both drivers report 0x as vendor/device id, and the maximum
> amount of system memory as video memory. We might want to reconsider
> the latter.
>
> Cc: Brian Paul
> Signed-off-by: Emil Velikov
> ---
> src/gallium/drivers/llvmpipe/lp_screen.c
- Original Message -
> From: "Emil Velikov"
> To: "Roland Scheidegger" , mesa-dev@lists.freedesktop.org
> Cc: "emil l velikov"
> Sent: Saturday, February 22, 2014 2:02:08 PM
> Subject: Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_g
Am 23.02.2014 16:26, schrieb Emil Velikov:
> On 22/02/14 21:46, Roland Scheidegger wrote:
>>
>>
>> - Original Message -
>>> From: "Emil Velikov"
>>> To: "Roland Scheidegger" ,
>>> mesa-dev@lists.freedesktop.org
>&g
Am 24.02.2014 09:33, schrieb Dave Airlie:
> On Wed, Feb 12, 2014 at 9:10 AM, Roland Scheidegger
> wrote:
>> Am 11.02.2014 22:58, schrieb Dave Airlie:
>>>>>dst.z = texture_depth(unit, lod)
>>>>>
>>>>> +.. opcode:: TG4 - Texture Gather
Am 24.02.2014 09:38, schrieb Dave Airlie:
> I've taken a quick look at ARB_texture_query_levels,
>
> and the HW generally seems to implement this by returning it in the W
> channel of RESINFO, which would map to the TXQ instruction,
>
> So my initial implementation added a LEVQ TGSI instruction b
with non-gl
state trackers so querying the drivers that way ultimately makes not
much sense).
I'm not really against a gl version cap bit cause it looks like it would
be a pain otherwise, just pointing out that fundamentally this is really
a bit of a hack.
Roland
> Marek
>
> On
Am 24.02.2014 21:54, schrieb Marek Olšák:
> On Mon, Feb 24, 2014 at 9:43 PM, Roland Scheidegger
> wrote:
>> Am 24.02.2014 21:23, schrieb Marek Olšák:
>>> Roland,
>>>
>>> The version CAPs that Emil wants to add have very little to do with
>>> which
Am 25.02.2014 00:00, schrieb Matt Turner:
> ---
> src/glsl/opt_algebraic.cpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 778638c..50342ac 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
>
slices * spr->stride[level]);
> + buffer_size += (uint64_t) util_format_get_nblocksy(pt->format, height)
> *
> + slices * spr->stride[level];
>
>width = u_minify(width, 1);
>height = u_minify(height, 1);
>
Re
Just one minor bug, otherwise
Reviewed-by: Roland Scheidegger
Am 28.02.2014 18:59, schrieb Brian Paul:
> Update the comments for the packed formats to accurately reflect the
> layout of the bits in the pixel. For example, for the packed format
> MESA_FORMAT_R8G8B8A8, R is in
) & 0xf) * (1.0F / 15.0F);
> - texel[GCOMP] = ((s >> 12) & 0xf) * (1.0F / 15.0F);
> - texel[BCOMP] = ((s >> 8) & 0xf) * (1.0F / 15.0F);
> - texel[ACOMP] = ((s >> 4) & 0xf) * (1.0F / 15.0F);
> +
Am 04.03.2014 05:08, schrieb Zack Rusin:
> draw_current_shader_* functions return a final output when considering
> both the geometry shader and the vertex shader. But when code generating
> vertex shader we can not be using output slots from the geometry shader
> because, obviously, those can be c
Am 06.03.2014 18:32, schrieb Jose Fonseca:
>
>
> - Original Message -
>>
>>
>> - Original Message -
>>> On 03/06/2014 09:59 AM, jfons...@vmware.com wrote:
From: José Fonseca
With the recent SRGB changes all my automated OpenGL llvmpipe tests
(piglit, conform,
Just one typo otherwise looks good (though I couldn't tell if it would
be missing in one of these swtich statements...).
Roland
Am 06.03.2014 18:58, schrieb Brian Paul:
> To match PIPE_FORMAT_R8G8B8A8_SRGB.
> ---
> src/mesa/main/format_pack.c | 27 +++
> src/mesa/m
Am 06.03.2014 19:25, schrieb Brian Paul:
> Cc: "10.0" "10.1"
> ---
> src/mesa/main/format_pack.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
> index e0d2a18..89958f7 100644
> --- a/src/mesa/main/format_
Am 07.03.2014 05:47, schrieb Chia-I Wu:
> On Fri, Mar 7, 2014 at 11:56 AM, Chia-I Wu wrote:
>> On Fri, Mar 7, 2014 at 2:04 AM, Jose Fonseca wrote:
>>>
>>>
>>> - Original Message -
Am 06.03.2014 18:32, schrieb Jose Fonseca:
>
>
> - Original Message -
>>
>>
Reviewed-by: Roland Scheidegger
Am 07.03.2014 04:09, schrieb Zack Rusin:
> (This version includes comments from Roland.)
>
> D3D10 allows setting of the internal offset of a buffer, which is
> in general only incremented via actual stream output writes. By
> allowing setting
Am 07.03.2014 18:55, schrieb Brian Paul:
> ---
> src/mesa/state_tracker/st_manager.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_manager.c
> b/src/mesa/state_tracker/st_manager.c
> index 68cb5de..314d342 100644
> --- a/src/mesa/state
Am 11.03.2014 01:23, schrieb Ian Romanick:
> I had a pretty similar patch on the top of my pow-optimization branch.
> I also expand x**3 and x**4. I had hoped that would enable some cases
> to expand then merge to MADs. It should also be faster on older GENs
> where POW perf sucks. I didn't send
Am 11.03.2014 17:29, schrieb Ian Romanick:
> On 03/10/2014 07:21 PM, Roland Scheidegger wrote:
>> Am 11.03.2014 01:23, schrieb Ian Romanick:
>>> I had a pretty similar patch on the top of my pow-optimization branch.
>>> I also expand x**3 and x**4. I had hoped that wou
Am 12.03.2014 15:00, schrieb Marek Olšák:
> Hi everybody,
>
> u_gen_mipmap doesn't disable queries, so all active queries are
> incremented, even though mipmap generation shouldn't have any effect
> on queries. Hardware drivers can disable queries, but this feature is
> not exposed via the gallium
Am 15.03.2014 18:17, schrieb Marek Olšák:
> From: Marek Olšák
>
> This is needed by _mesa_generate_mipmap.
>
> This adds an array of pipe_transfers to st_texture_image. Each transfer is
> for mapping a single layer. It's ugly, but at least _mesa_generate_mipmap
> works for array textures.
> ---
Am 19.03.2014 10:44, schrieb Kenneth Graunke:
> Traditionally, we've implemented fragment color clamping by emitting
> "mov.sat" in the fragment shader's final color write code, clamping
> the output to [0, 1] prior to blending. (When clamping is off, we
> use a regular "mov".) This means we have
Am 19.03.2014 18:12, schrieb Richard Sandiford:
> The AoS version of ld_build_blend_factor was assuming that if the first
> channel was alpha, there were no rgb components.
>
> Fixes glean/blendFunc on System z. No piglit regressions on x86_64.
> The shortcut is still used in tests like spec/ARB_
Am 16.03.2014 15:47, schrieb Marek Olšák:
> From: Marek Olšák
>
> It may cause issues with mipmap generation.
> I think it was used to make some piglit tests pass on r300g.
> ---
> src/gallium/auxiliary/util/u_blitter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sr
Am 16.03.2014 15:47, schrieb Marek Olšák:
> From: Marek Olšák
>
> This replaces u_gen_mipmap with an extremely simple implementation based
> on pipe->blit. The diff speaks for itself. st/mesa is also cleaned up.
>
> Pros:
> - less code
> - correct mipmap generation for NPOT 3D textures (u_blitte
Am 22.03.2014 16:54, schrieb Roland Scheidegger:
> Am 16.03.2014 15:47, schrieb Marek Olšák:
>> From: Marek Olšák
>>
>> This replaces u_gen_mipmap with an extremely simple implementation based
>> on pipe->blit. The diff speaks for itself. st/mesa is also cleaned
> On Sat, Mar 22, 2014 at 4:54 PM, Roland Scheidegger
> wrote:
> > I think this is missing some parameters by not using a sampler view. In
> > particular can we please have a separate format here? It may not matter
> > for GL (srgb maybe, texture views?), but for this to w
Am 22.03.2014 18:15, schrieb Brian Paul:
> On 03/21/2014 04:01 PM, Anuj Phogat wrote:
>> Cc:
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/main/format_unpack.c | 79
>> ++-
>> src/mesa/main/format_unpack.h | 5 +++
>> 2 files changed, 83 insertions(
Am 23.03.2014 12:36, schrieb Christian König:
> Am 22.03.2014 23:33, schrieb Brian Paul:
>> On Sat, Mar 22, 2014 at 2:49 PM, Christian König
>> mailto:deathsim...@vodafone.de>> wrote:
>>
>> Hi guys,
>>
>> recently some XBMC users complained about crashes with the
>> relatively new NV_vd
Am 24.03.2014 16:31, schrieb jfons...@vmware.com:
> From: José Fonseca
>
> Eliminate lp_vertex_shader, as it added nothing over draw_vertex_shader.
>
> Simplify lp_geometry_shader, as most of the incoming state is unneeded.
> (We could also just use draw_geometry_shader if we were willing to pee
Am 25.03.2014 22:36, schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/include/pipe/p_context.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index fe3045a..bf27285 100644
Am 25.03.2014 23:48, schrieb Ilia Mirkin:
> On Tue, Mar 25, 2014 at 6:32 PM, Roland Scheidegger
> wrote:
>> Am 25.03.2014 22:36, schrieb Ilia Mirkin:
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>> src/gallium/include/pipe/p_context.h | 11 +++
Am 26.03.2014 03:29, schrieb Marek Olšák:
> My reasoning was that it would be better to specify a raw clear value
> and clear value size for buffers, which are always untyped, and
> pipe_color_union for textures, which are always typed, so that drivers
> can easily implement the texture clearing on
hing and they are fixed up in the end
this series is:
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 22.03.2014 18:27, schrieb Brian Paul:
> And use the z32f_x24s8 helper struct in unpack_Z32_FLOAT_X24S8().
> Cc: "10.0" "10.1"
> ---
> src/mesa/main/format_unpack.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main
o allocate the gallium query earlier.
> + * Return TRUE so we don't spin on this forever.
> + */
> + return TRUE;
> + }
> +
> if (!pipe->get_query_result(pipe,
> stq->pq,
> wait,
>
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 26.03.2014 18:37, schrieb Zack Rusin:
> We used to overallocate the output buffer sometimes running out
> of memory with applications rendering large geometries. The actual
> maximum number of vertices out is simply the maximum number of
> primitives in (number of gs invocations) multiplied by t
Marek,
what are your plans for this change?
Roland
Am 22.03.2014 20:03, schrieb Roland Scheidegger:
>> On Sat, Mar 22, 2014 at 4:54 PM, Roland Scheidegger
>> wrote:
>>> I think this is missing some parameters by not using a sampler view. In
>>> particular can we
Am 27.03.2014 03:04, schrieb Marek Olšák:
> On Wed, Mar 26, 2014 at 4:30 AM, Roland Scheidegger
> wrote:
>> Am 26.03.2014 03:29, schrieb Marek Olšák:
>>> My reasoning was that it would be better to specify a raw clear value
>>> and clear value size for buffers,
Am 28.03.2014 05:06, schrieb Kenneth Graunke:
>
> I've attached the info for everything on the i965 driver. In case you
> ever want to regenerate things, I just ran:
>
> $ INTEL_DEVID_OVERRIDE=0x29a2 glxinfo -l -s &> gen4
> $ INTEL_DEVID_OVERRIDE=0x2a42 glxinfo -l -s &> gen4.5
> $ INTEL_DEVID_OV
Am 28.03.2014 22:18, schrieb Ilia Mirkin:
> Hey guys,
>
> I was thinking of taking a shot at implementing ARB_sample_shading for
> nv50 (well, nva3-nva8) this weekend. One of the issues is that it's
> not implemented in gallium at all right now, so I need to pipe it
> through somehow. I believe th
Am 28.03.2014 22:56, schrieb Ilia Mirkin:
> On Fri, Mar 28, 2014 at 5:47 PM, Roland Scheidegger
> wrote:
>> Am 28.03.2014 22:18, schrieb Ilia Mirkin:
>>> Hey guys,
>>>
>>> I was thinking of taking a shot at implementing ARB_sample_shading for
>>>
Am 28.03.2014 23:57, schrieb Ilia Mirkin:
> On Fri, Mar 28, 2014 at 6:41 PM, Roland Scheidegger
> wrote:
>> Am 28.03.2014 22:56, schrieb Ilia Mirkin:
>>> On Fri, Mar 28, 2014 at 5:47 PM, Roland Scheidegger
>>> wrote:
>>>> Am 28.03.2014 22:18, schrieb
701 - 800 of 2245 matches
Mail list logo
