CB updates to bound buffers need to go through the CB_DATA endpoints,
otherwise the shader may not notice that the updates happened.
Furthermore, these updates have to go in to the same address as the
bound buffer, otherwise, again, the shader may not notice updates.
So we keep track of all the pl
On 07.09.2015 07:17, Marek Olšák wrote:
> From: Marek Olšák
>
> We will only do depth-only or stencil-only decompress blits, whichever is
> needed by textures, instead of always doing both.
> ---
> src/gallium/drivers/r600/evergreen_state.c| 4 ++--
> src/gallium/drivers/r600/r600_state_comm
On 07.09.2015 07:17, Marek Olšák wrote:
> From: Marek Olšák
>
> instead of always doing both.
> Usually, only depth is needed, so stencil decompression is useless.
[...]
> @@ -247,6 +256,7 @@ void si_flush_depth_textures(struct si_context *sctx,
> assert(tex->is_depth && !tex->is_
On Thu, Sep 03, 2015 at 11:08:11AM -0700, Ian Romanick wrote:
> On 09/03/2015 09:05 AM, Chris Wilson wrote:
> > If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> > and specifies a generic unsized GL_RGB internal format, match that to a
> > texture format of MESA_FORMAT_B5G6R
On Thu, Sep 3, 2015 at 6:05 PM, Chris Wilson wrote:
> If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> and specifies a generic unsized GL_RGB internal format, match that to a
> texture format of MESA_FORMAT_B5G6R5 if supported by the hardware.
>
> Noticed while playing wit
On Wed, Sep 09, 2015 at 11:11:59AM +0200, Erik Faye-Lund wrote:
> On Thu, Sep 3, 2015 at 6:05 PM, Chris Wilson wrote:
> > If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> > and specifies a generic unsized GL_RGB internal format, match that to a
> > texture format of MESA_F
On Wed, Sep 9, 2015 at 11:25 AM, Chris Wilson wrote:
> On Wed, Sep 09, 2015 at 11:11:59AM +0200, Erik Faye-Lund wrote:
>> On Thu, Sep 3, 2015 at 6:05 PM, Chris Wilson
>> wrote:
>> > If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
>> > and specifies a generic unsized GL_RG
On 08/09/15 18:52, Jordan Justen wrote:
> On 2015-08-05 01:30:20, Iago Toral Quiroga wrote:
>> From: Samuel Iglesias Gonsalvez
>>
>> Signed-off-by: Samuel Iglesias Gonsalvez
>> ---
>> src/glsl/lower_ubo_reference.cpp | 65
>> ++--
>> 1 file changed, 49 inse
On 31/08/15 08:38, Samuel Iglesias Gonsálvez wrote:
>
>
> On 29/08/15 02:27, Jordan Justen wrote:
>> On 2015-08-05 01:30:17, Iago Toral Quiroga wrote:
>>> From: Samuel Iglesias Gonsalvez
>>>
>>> This commit also adds functions to calculate std430 base alignment and sizes
>>>
>>> Signed-off-by:
On 08/09/15 19:50, Jordan Justen wrote:
> On 2015-08-05 01:30:21, Iago Toral Quiroga wrote:
>> From: Samuel Iglesias Gonsalvez
>>
>> Otherwise, generate a link time error as per the
>> ARB_shader_storage_buffer_object spec.
>>
>> Signed-off-by: Samuel Iglesias Gonsalvez
>> ---
>> src/glsl/glsl
The following patches do some preparatory refactoring in softpipe's
sp_tex_sample.{c,h} before actually implementing the feature.
There is also a patch that fixes softpipe's textureLod with bias. I
caught this bug when finished the textureQueryLod implementation - one
of four textureQueryLod tests
These functions will be used by textureQueryLod.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 100 +--
src/gallium/drivers/softpipe/sp_tex_sample.h | 7 ++
2 files changed, 101 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
It clearly is here by accident.
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 75cd0d5..9544623 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
textureQueryLod returns a vec2 with a mipmap information and a
LOD. The latter needs to be not clamped.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 55
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c
This introduces new vfunc in tgsi_sampler just for this opcode. I
decided against extending get_samples vfunc to return the mipmap level
and LOD - the function's prototype is already too scary and doing the
sampling for textureQueryLod would be a waste of time.
---
src/gallium/auxiliary/tgsi/tgsi_
This function will be later used by textureQueryLod. The
img_filter_func are optional, because textureQueryLod will not need
them.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 53 +++-
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers
The level-of-detail bias wasn't simply added in the explicit LOD case.
This case seems to be tested only in piglit's
fs-texturequerylod-nearest-biased test, which is currently skipped, as
softpipe does not support textureQueryLod at the moment.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 2
Passes the shader piglit tests and introduces no regressions.
This commit finally makes use of the refactoring in previous
commits.
---
src/gallium/drivers/softpipe/sp_screen.c | 2 +-
src/gallium/drivers/softpipe/sp_tex_sample.c | 47 +++-
2 files changed, 47 inserti
This is to avoid tying the conversion to sampling - textureQueryLod
will need to do the conversion too, but it does not do any sampling.
So instead of a "sample" vfunc, there is a "convert" vfunc. The
drawback of this approach is that a "noop" convert copies 3 arrays of
floats. Would be nice to av
Putting this function pointer into a struct enables grouping of
several related functions in a single place. For now it is just a
single function, but the struct will be later extended with a
mip_level_func for returning mip level.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 28
On Wed, Sep 09, 2015 at 12:09:40PM +0200, Erik Faye-Lund wrote:
> On Wed, Sep 9, 2015 at 11:25 AM, Chris Wilson
> wrote:
> > On Wed, Sep 09, 2015 at 11:11:59AM +0200, Erik Faye-Lund wrote:
> >> On Thu, Sep 3, 2015 at 6:05 PM, Chris Wilson
> >> wrote:
> >> > If the user supplies a pixel format o
https://bugs.freedesktop.org/show_bug.cgi?id=80821
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Comparison with a signed expression and unsigned value
is converted to unsigned value, reason for minus value is interpreted
as a big unsigned value. For this case the "for" loop
is going into unexpected behavior.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109
Signed-off-by: Marius P
Mark Janes writes:
> Francisco Jerez writes:
>
>> Mark Janes writes:
>>
>>> When I tested this, I saw an intermittent BSW gpu hang. I haven't been
>>> able to confirm that it is due to the host-mem-barrier test.
>>>
>> It would probably be useful to know if the hang is due to any of the
>> ima
Ian Romanick writes:
> On 09/03/2015 06:03 AM, Francisco Jerez wrote:
>> IVB and VLV hang sporadically when an untyped surface read or write
>> message is used to access a surface of format other than RAW, as may
>> happen when there is a mismatch between the format qualifier of the
>> image unif
On PNV platform, for 1 pixel line thickness or less,
the general anti-aliasing algorithm gives up, and a garbage line is generated.
Setting a Line Width of 0.0 specifies the rasterization
of the "thinnest" (one-pixel-wide), non-antialiased lines.
Lines rendered with zero Line Width are rasterized u
Am 09.09.2015 um 05:56 schrieb Ian Romanick:
> On 08/15/2015 02:24 AM, Francisco Jerez wrote:
>> Roland Scheidegger writes:
>>
>>> I guess though you'd need these bits when implementing things like
>>> ARB_fragment_shader_ordering? (Thus stuff actually looks useful but I
>>> don't know if anybody
On Sun, Sep 6, 2015 at 4:28 AM, Lauri Kasanen wrote:
> On Sat, 5 Sep 2015 23:29:05 +
> Albert Freeman wrote:
>
>> The reply from Eric Anholt made two suggestions that should not be
>> difficult to implement for someone who made the patch in the first
>> place. Why would code be committed when
Comparison with a signed expression and unsigned value
is converted to unsigned value, reason for minus value is interpreted
as a big unsigned value. For this case the "for" loop
is going into unexpected behavior.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109
Signed-off-by: Marius P
On Wed, 9 Sep 2015 09:11:50 -0400
Alex Deucher wrote:
> > Oh, absolutely - I had no issues with "this needs changing". My issue
> > was with the fact it took months to get that. Had I come up with a new
> > patch, it would likely have taken a similar time, months again, which
> > did not inspire
Since _mesa_update_state() may be called several times per draw call,
we wish to be judicious about the amount of work we place inside the
intel_update_state() callback. By moving the current HiZ/color resolves
we need before drawing from out of the notify and into the draw itself,
we can save a fe
Performing the HiZ/color resolves is a fairly heavyweight operation that
we don't need to perform on every state update, only before use the
unresolved surfaces in a draw call. Since we use meta operations to
perform the resolve, we cannot do so from inside brw_draw_prims() itself
(as that will ree
When we come to flush the vertices, we need to clear the NeedFlush
flag first before calling into the backend as that backend may trigger
FLUSH_VERTICES() itself (through use of meta) before dirtying the vertex
state. If the NeedFlush flag is still in place, we end up recursing
into the backend aga
Now that we moved the resolving from out of the _mesa_update_state()
callback we can remove the trick of calling _mesa_update_state() again
from inside the resolver (as we no longer need to adhere to the
_mesa_update_state() contract). However, we still need to make sure that
the context is up to d
The very first operation performed by _mesa_readpixels() is to call
_mesa_update_state() - we do not need to do so ourselves.
Signed-off-by: Chris Wilson
Cc: Jordan Justen
Cc: Jason Ekstrand
Cc: Kenneth Graunke
Cc: Francisco Jerez
---
src/mesa/drivers/dri/i965/intel_pixel_read.c | 8
Only walk through the set of enabled TextureUnits looking for a texture
that needs to be resolved if the context state flags a new texture.
Note that this will miss if the client is rendering into a texture that
it is reading from, though that needs explicit barriers (and futhermore
no piglits com
A common problem with using HiZ and multisampling is that surfaces need
to resolved prior to use. Currently i965 does this inside its state
update hook, but that is a comparatively heavyweight operation that need
not be performed so frequently. The obvious solution (and therefore
fraught with drago
Hi,
On 08-09-15 09:53, Hans de Goede wrote:
Hi,
On 07-09-15 21:55, Ilia Mirkin wrote:
May I ask why you're doing 512x512 instead of 1024x1024? These are
already scaled up coordinates, so 1024x1024 should work no? Or is it
because of the seams on the edges? Do those not also appear with
512x512
Having checked whether the base class (gl_texture_object) is NULL, we
know that intel_texture_object itself cannot be NULL.
Signed-off-by: Chris Wilson
Cc: Jordan Justen
Cc: Jason Ekstrand
Cc: Kenneth Graunke
Cc: Francisco Jerez
---
src/mesa/drivers/dri/i965/brw_draw.c | 7 +--
1 file ch
Am 09.09.2015 um 15:04 schrieb Roland Scheidegger:
> Am 09.09.2015 um 05:56 schrieb Ian Romanick:
>> On 08/15/2015 02:24 AM, Francisco Jerez wrote:
>>> Roland Scheidegger writes:
>>>
I guess though you'd need these bits when implementing things like
ARB_fragment_shader_ordering? (Thus st
We do not have a generic blitter on nv3x cards, so we must use the
sifm object for color resolving.
This commit divides the sources and dest surfaces in to tiles which
match the constraints of the sifm object, so that color resolving
will work properly on nv3x cards.
Signed-off-by: Hans de Goede
Some modern apps try to use msaa without keeping in mind the
restrictions on videomem of older cards. Resulting in dmesg saying:
[ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
[ 1197.850654] nouveau E[soffice.bin[3785
On 09/09/2015 08:16 AM, Marius Predut wrote:
Comparison with a signed expression and unsigned value
is converted to unsigned value, reason for minus value is interpreted
as a big unsigned value. For this case the "for" loop
is going into unexpected behavior.
Bugzilla: https://bugs.freedesktop.or
On 09/09/2015 07:59 AM, Marius Predut wrote:
On PNV platform, for 1 pixel line thickness or less,
the general anti-aliasing algorithm gives up, and a garbage line is generated.
Setting a Line Width of 0.0 specifies the rasterization
of the "thinnest" (one-pixel-wide), non-antialiased lines.
Lines
On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski wrote:
> From: Chris Wilson
>
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own o
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
The following patches do some preparatory refactoring in softpipe's
sp_tex_sample.{c,h} before actually implementing the feature.
There is also a patch that fixes softpipe's textureLod with bias. I
caught this bug when finished the textureQueryLod i
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
Putting this function pointer into a struct enables grouping of
several related functions in a single place. For now it is just a
single function, but the struct will be later extended with a
mip_level_func for returning mip level.
---
src/gallium/
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
textureQueryLod returns a vec2 with a mipmap information and a
LOD. The latter needs to be not clamped.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 55
1 file changed, 39 insertions(+), 16 deletions(-)
diff --g
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
This function will be later used by textureQueryLod. The
img_filter_func are optional, because textureQueryLod will not need
them.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 53 +++-
1 file changed, 37 insertions(+)
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
This is to avoid tying the conversion to sampling - textureQueryLod
will need to do the conversion too, but it does not do any sampling.
So instead of a "sample" vfunc, there is a "convert" vfunc. The
drawback of this approach is that a "noop" conve
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
These functions will be used by textureQueryLod.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 100 +--
src/gallium/drivers/softpipe/sp_tex_sample.h | 7 ++
2 files changed, 101 insertions(+), 6 deletions(-)
diff -
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
This introduces new vfunc in tgsi_sampler just for this opcode. I
decided against extending get_samples vfunc to return the mipmap level
and LOD - the function's prototype is already too scary and doing the
sampling for textureQueryLod would be a was
On 09/09/2015 04:35 AM, Krzesimir Nowak wrote:
Passes the shader piglit tests and introduces no regressions.
This commit finally makes use of the refactoring in previous
commits.
---
src/gallium/drivers/softpipe/sp_screen.c | 2 +-
src/gallium/drivers/softpipe/sp_tex_sample.c | 47 ++
From: Chris Wilson
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
Softpin allows userspace to take greater control of GPU virtual address
space and eliminates the need of relocations. It can also be used to
mirror addresses between GPU and CPU (shared virtual memory).
Calls to drm_intel_bo_emit_reloc are still required to build the list of
drm_i915_gem_exec_objec
While support for 48b ppgtt is here, parameter enabling it is not known
to the sanitize function. Let's update it to allow selecting
full_48bit_ppgtt using module parameter.
Cc: Michel Thierry
Cc: Mika Kuoppala
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
The goal of this series is to start a discussion whether the interface and
implementation of softpin support proposed for libdrm is acceptable by all
interested parties.
The i915 patches are added so that it's easy to apply the series on latest
drm-intel-nightly and libdrm master and start using so
On Wed, Sep 9, 2015 at 9:52 AM, Hans de Goede wrote:
> We do not have a generic blitter on nv3x cards, so we must use the
> sifm object for color resolving.
>
> This commit divides the sources and dest surfaces in to tiles which
> match the constraints of the sifm object, so that color resolving
>
On Wed, Sep 9, 2015 at 9:52 AM, Hans de Goede wrote:
> Some modern apps try to use msaa without keeping in mind the
> restrictions on videomem of older cards. Resulting in dmesg saying:
>
> [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
> [ 1197.850648] nouveau E[soffice.bin[3785]
"r600g: apply disable workaround on all scissors" forgot to update
num_dw, fix it.
Fixes: fbb423b433 "r600g: apply disable workaround on all scissors"
Reported-and-tested-by: Markus Trippelsdorf
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91921
---
src/gallium/drivers/r600/r600_state_
On Tue, Sep 08, 2015 at 01:16:11PM -0700, Ian Romanick wrote:
> On 09/06/2015 09:37 AM, Chris Wilson wrote:
> > glCopyTexImage behaves similarly to glReadPixels with respect to the
> > pixel transfer operations. Therefore if any are set we cannot use the
> > simply blit fast paths.
>
> Do we have
On Wed, Sep 9, 2015 at 12:44 PM, Chris Wilson wrote:
> On Tue, Sep 08, 2015 at 01:16:11PM -0700, Ian Romanick wrote:
>> On 09/06/2015 09:37 AM, Chris Wilson wrote:
>> > glCopyTexImage behaves similarly to glReadPixels with respect to the
>> > pixel transfer operations. Therefore if any are set we
On 09/08/2015 10:43 PM, Kenneth Graunke wrote:
> On Tuesday, September 08, 2015 08:50:41 PM Ian Romanick wrote:
>> On 09/08/2015 06:04 PM, Kenneth Graunke wrote:
>>> Our old value of 16384 is the minimum value. DirectX apparently
>>> requires 65536 at a minimum; that's also what nVidia and the Int
On 09/09/2015 05:30 AM, Francisco Jerez wrote:
> Ian Romanick writes:
>
>> On 09/03/2015 06:03 AM, Francisco Jerez wrote:
>>> IVB and VLV hang sporadically when an untyped surface read or write
>>> message is used to access a surface of format other than RAW, as may
>>> happen when there is a mis
On Wednesday, September 09, 2015 02:38:56 PM Chris Wilson wrote:
> A common problem with using HiZ and multisampling is that surfaces need
> to resolved prior to use. Currently i965 does this inside its state
> update hook, but that is a comparatively heavyweight operation that need
> not be perfor
On Sep 8, 2015 23:27, "Eduardo Lima Mitev" wrote:
>
> This pass will propagate the destination components of a vecN
instructions,
> as destination of the instructions that define its sources; if certain
> conditions are met.
>
> If all the components of the destination register in the vecN instruc
Comparison with a signed expression and unsigned value
is converted to unsigned value, reason for minus value is interpreted
as a big unsigned value. For this case the "for" loop
is going into unexpected behavior.
v1:Brian Paul: code style fix.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
On 09/09/2015 10:10 AM, Kenneth Graunke wrote:
> On Wednesday, September 09, 2015 02:38:56 PM Chris Wilson wrote:
>> A common problem with using HiZ and multisampling is that surfaces need
>> to resolved prior to use. Currently i965 does this inside its state
>> update hook, but that is a comparati
On Wednesday, September 09, 2015 10:19:10 AM Ian Romanick wrote:
> On 09/09/2015 10:10 AM, Kenneth Graunke wrote:
> > On Wednesday, September 09, 2015 02:38:56 PM Chris Wilson wrote:
> >> A common problem with using HiZ and multisampling is that surfaces need
> >> to resolved prior to use. Currentl
Just a minor nitpick.
Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak:
> textureQueryLod returns a vec2 with a mipmap information and a
> LOD. The latter needs to be not clamped.
> ---
> src/gallium/drivers/softpipe/sp_tex_sample.c | 55
>
> 1 file changed, 39 inserti
In trying to separate the backend compiler from the core driver, I ran
into a couple of inconsistencies with how the compute shader code is
split across files. First patch moves code around to follow our
convention. The last two patches moves fs precompile and perf debug
around to move libdrm depen
All other precompile functions live in the brw_.c files, make fs
follow the convention.
Signed-off-by: Kristian Høgsberg Kristensen
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 58 ---
src/mesa/drivers/dri/i965/brw_wm.c | 59
2
We're trying to avoid a libdrm dependency in the core compiler, so let's
move the perf_debug code one level up from the brw_*_emit() helpers to
the brw_codegen_*_prog() helpers.
Signed-off-by: Kristian Høgsberg Kristensen
---
src/mesa/drivers/dri/i965/brw_cs.c | 31 -
This moves the compute shader code around in order to make the way the
code is split up more consistent. There should be no functional changes.
Typically we have a few files per stage:
brw_vs.c, brw_wm.c brw_gs.c:
code to drive code generation and implement precompiling and
ca
On Wed, Sep 9, 2015 at 3:17 AM, Ilia Mirkin wrote:
> CB updates to bound buffers need to go through the CB_DATA endpoints,
> otherwise the shader may not notice that the updates happened.
> Furthermore, these updates have to go in to the same address as the
> bound buffer, otherwise, again, the sh
Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak:
> This function will be later used by textureQueryLod. The
> img_filter_func are optional, because textureQueryLod will not need
> them.
> ---
> src/gallium/drivers/softpipe/sp_tex_sample.c | 53
> +++-
> 1 file changed, 37 i
On 9 September 2015 at 01:43, Ian Romanick wrote:
> On 09/07/2015 01:58 AM, Emil Velikov wrote:
>> From: Matt Turner
>>
>> v2: [Emil Velikov]
>> Rework the error path to a common goto, close only if we own the fd.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/egl/drivers/dri2/platform_drm.c |
Regardless of what happens with the rest of this series, I think this is
a reasonable cleanup. This patch is
Reviewed-by: Ian Romanick
On 09/09/2015 06:38 AM, Chris Wilson wrote:
> The very first operation performed by _mesa_readpixels() is to call
> _mesa_update_state() - we do not need to do
https://bugs.freedesktop.org/show_bug.cgi?id=91793
--- Comment #4 from Emil Velikov ---
Just had a closer look and it seems that the wgl tests are only build with
cmake. Situation seems slightly confusing atm, but if you feel like helping out
that'll be appreciated :)
--
You are receiving this
On 09/09/2015 06:39 AM, Chris Wilson wrote:
> Having checked whether the base class (gl_texture_object) is NULL, we
> know that intel_texture_object itself cannot be NULL.
>
> Signed-off-by: Chris Wilson
> Cc: Jordan Justen
> Cc: Jason Ekstrand
> Cc: Kenneth Graunke
> Cc: Francisco Jerez
> --
Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak:
> This is to avoid tying the conversion to sampling - textureQueryLod
> will need to do the conversion too, but it does not do any sampling.
>
> So instead of a "sample" vfunc, there is a "convert" vfunc. The
> drawback of this approach is that a "no
From: Ian Romanick
Previously the result of the complicated clamp() expression just dropped
on the floor: clamp does not modify any of its parameters. Looking at
the surrounding code, I believe this is supposed to modify the value of
tex_coord.
This change (along with a change to avoid the use
On 09/09/2015 11:13 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Previously the result of the complicated clamp() expression just dropped
> on the floor: clamp does not modify any of its parameters. Looking at
> the surrounding code, I believe this is supposed to modify the value of
> tex_co
Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak:
> These functions will be used by textureQueryLod.
> ---
> src/gallium/drivers/softpipe/sp_tex_sample.c | 100
> +--
> src/gallium/drivers/softpipe/sp_tex_sample.h | 7 ++
> 2 files changed, 101 insertions(+), 6 deletions(-
On Wed, Sep 9, 2015 at 2:17 PM, Roland Scheidegger wrote:
> Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak:
>> These functions will be used by textureQueryLod.
>> ---
>> src/gallium/drivers/softpipe/sp_tex_sample.c | 100
>> +--
>> src/gallium/drivers/softpipe/sp_tex_samp
Yes, using a new function is definitely the right way to go imho.
Apart from the things mentioned by Brian, the series looks good to me.
Roland
Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak:
> This introduces new vfunc in tgsi_sampler just for this opcode. I
> decided against extending get_sampl
I'm pretty sure our implementation of this extension is complete
rubbish. I have attached an image from the blit-scaled test. This
result cannot be useful to anyone.
On 09/09/2015 11:16 AM, Ian Romanick wrote:
> On 09/09/2015 11:13 AM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Previously
In case it's of any interest, nouveau fails many of the blit-scaled
tests. However nouveau's MS blits are notoriously bad. [I think I know
what's wrong, just don't have the energy to fix it.]
OTOH the NVIDIA driver also fails at every scale factor (for 2x and
8x, passes for 4x).
On Wed, Sep 9, 20
On 09/09/2015 10:59 AM, Emil Velikov wrote:
> On 9 September 2015 at 01:43, Ian Romanick wrote:
>> On 09/07/2015 01:58 AM, Emil Velikov wrote:
>>> From: Matt Turner
>>>
>>> v2: [Emil Velikov]
>>> Rework the error path to a common goto, close only if we own the fd.
>>>
>>> Signed-off-by: Emil Veli
On Tue, Sep 1, 2015 at 6:58 AM, Emil Velikov wrote:
> Hi all
>
> On 21 August 2015 at 23:04, Anuj Phogat wrote:
>> We have a similar check in meta pbo path.
>>
>> Cc:
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/drivers/dri/i965/intel_pixel_read.c | 4
>> 1 file changed, 4 insertions(
On 09/09/2015 11:16 AM, Marius Predut wrote:
> Comparison with a signed expression and unsigned value
> is converted to unsigned value, reason for minus value is interpreted
> as a big unsigned value. For this case the "for" loop
> is going into unexpected behavior.
>
> v1:Brian Paul: code style f
On 09/09/2015 11:53 AM, Ian Romanick wrote:
> On 09/09/2015 11:16 AM, Marius Predut wrote:
>> Comparison with a signed expression and unsigned value
>> is converted to unsigned value, reason for minus value is interpreted
>> as a big unsigned value. For this case the "for" loop
>> is going into une
On 09/09/2015 06:59 AM, Marius Predut wrote:
> On PNV platform, for 1 pixel line thickness or less,
> the general anti-aliasing algorithm gives up, and a garbage line is generated.
> Setting a Line Width of 0.0 specifies the rasterization
> of the "thinnest" (one-pixel-wide), non-antialiased lines.
Jordan Justen writes:
> Signed-off-by: Jordan Justen
>
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
Marius Predut writes:
> Comparison with a signed expression and unsigned value
> is converted to unsigned value, reason for minus value is interpreted
> as a big unsigned value. For this case the "for" loop
> is going into unexpected behavior.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.c
Both st/mesa and the NVIDIA fail framebuffer completeness on this
command sequence:
270 glRenderbufferStorageMultisample(target = GL_RENDERBUFFER, samples
= 0, internalformat = GL_RGBA, width = 256, height = 256)
272 glFramebufferRenderbuffer(target = GL_DRAW_FRAMEBUFFER, attachment
= GL_COLOR_ATT
Reviewed-by: Ian Romanick
On 06/29/2015 12:35 AM, Tapani Pälli wrote:
> Signed-off-by: Tapani Pälli
> ---
> src/mesa/drivers/dri/i915/i915_context.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i915/i915_context.c
> b/src/mesa/drivers/dri/i915/i915_context.
Jordan Justen writes:
> Signed-off-by: Jordan Justen
I'd change the subject to something like
i965: Teach is_scalar_shader_stage() about compute shaders
since that's the change in the patch and it affects many other
lowering/optimization decisions.
With that,
Reviewed-by: Kristian Høgsbe
From: Ian Romanick
We may have been called from glGenerateTextureMipmap with CurrentUnit
still set to 0, so we don't know when we can skip binding the texture.
Assume that _mesa_BindTexture will be fast if we're rebinding the same
texture.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.free
Aha, apparently there's a 'depthstencil' option that uses a combined
RB. Nevermind! Didn't realize that was the case.
On Wed, Sep 9, 2015 at 3:24 PM, Ilia Mirkin wrote:
> Both st/mesa and the NVIDIA fail framebuffer completeness on this
> command sequence:
>
> 270 glRenderbufferStorageMultisample
1 - 100 of 144 matches
Mail list logo
