On Wed, 19 Nov 2014 15:32:38 +0900
Alexandre Courbot wrote:
> Some more information: CPU usage of the EGL app (glmark2 here) is much
> higher when this patch is applied, which I presume is what triggers the
> frame skips.
>
> On 11/19/2014 03:05 PM, Alexandre Courbot wrote:
> > Hi guys,
> >
>
On Tue, 2014-11-18 at 08:00 -0700, Brian Paul wrote:
> On 11/18/2014 02:23 AM, Iago Toral Quiroga wrote:
> > From: Samuel Iglesias Gonsalvez
> >
> > This covers glGetTexImage for uncompressed color formats.
> >
> > Signed-off-by: Samuel Iglesias Gonsalvez
> > Signed-off-by: Eduardo Lima Mitev
>
On Tue, 2014-11-18 at 10:46 -0800, Jason Ekstrand wrote:
>
>
> On Tue, Nov 18, 2014 at 12:43 AM, Iago Toral Quiroga
> wrote:
> From: Jason Ekstrand
>
> An array format is a 32-bit integer format identifier that can
> represent
> any format that can be re
On 19 November 2014 17:01, Benjamin Bellec wrote:
> Hello,
> Did you tried with R600_DEBUG=nosb ?
It won't fix any of the GS tests since they don't use sb at all,
I don't think it fixed the multisample tests either, and I tried a piglit
run with nosb and I feel over somewhere else.
Dave.
> Reg
Hello,
Did you tried with R600_DEBUG=nosb ?
Regards.
Le 19 nov. 2014 07:18, "Dave Airlie" a écrit :
> Hey,
>
> I got piglit to run on my laptop rv635,
>
> two things seem to hang it
>
> geometry shader texel fetches (wierd incorrect values for 2D, hangs for
> 2DMS)
> and
> the clip scissor msaa b
Some more information: CPU usage of the EGL app (glmark2 here) is much
higher when this patch is applied, which I presume is what triggers the
frame skips.
On 11/19/2014 03:05 PM, Alexandre Courbot wrote:
Hi guys,
I am seeing a severe performance regression (lots frame drops when
running EGL
Hey,
I got piglit to run on my laptop rv635,
two things seem to hang it
geometry shader texel fetches (wierd incorrect values for 2D, hangs for 2DMS)
and
the clip scissor msaa blits.
The main wierdness is that texelFetch gs sampler2D is busted,
you get wierd black lines in the middle of the re
Hi guys,
I am seeing a severe performance regression (lots frame drops when
running EGL apps in Weston) on Tegra/GK20A since the following commit:
commit 363b53f00069af718f64cf047f19ad5681a8bf6d
Author: Marek Olšák
Date: Sat Nov 1 14:31:09 2014 +0100
egl: remove egl_gallium from the lo
On 11/19/2014 02:49 PM, Ilia Mirkin wrote:
On Wed, Nov 19, 2014 at 12:41 AM, Alexandre Courbot wrote:
Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not use dedicated video memory.
Signed-off-by: Alexandre Courbot
---
src/gallium/driver
On Wed, Nov 19, 2014 at 12:41 AM, Alexandre Courbot wrote:
> Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
> VRAM domains for chips that do not use dedicated video memory.
>
> Signed-off-by: Alexandre Courbot
> ---
> src/gallium/drivers/nouveau/nouveau_buffer.c
This series is to allow NVIDIA chips with shared memory to operate more
efficiently (and to operate at all once we disable VRAM from the kernel
driver) by allowing nouveau_screen to specify a domain to use for objects
originally allocated into VRAM. If the domain is not overridden, the default
NOUV
Some NVIDIA chips (e.g. GK20A) do not embed VRAM of their own and have
complete shared access to system memory. For these systems, allocating
objects in VRAM might lead to unneeded copies and sub-optimal memory
management. It will also lead to errors if the kernel does not allow
VRAM objects alloca
Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not use dedicated video memory.
Signed-off-by: Alexandre Courbot
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++
src/gallium/drivers/nouveau/nv50/nv50_miptree.c|
GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
sub-optimal and sometimes even harmful. Set its VRAM domain to
NOUVEAU_BO_GART so all objects are allocated in system memory.
Signed-off-by: Alexandre Courbot
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 15 +
Mailman, wake up!
I sent this patch series to mesa-dev twice this evening. And each time,
only one patch (PATCH 3/4) got through to the mailing list. Weird.
git-send-email says that all mail was sent ok. Weird again.
If you want to see my patches, they're on my branch
'i965-safer-pointer-ari
This patch reduces the likelihood of pointer arithmetic overflow bugs in
intel_texsubimage_tiled_memcpy() , like the one fixed by b69c7c5dac.
I haven't yet encountered any overflow bugs in the wild along this
patch's codepath. But I recently solved, in commit b69c7c5dac, an overflow
bug in a line
This patch reduces the likelihood of pointer arithmetic overflow bugs in
intel_texsubimage_tiled_memcpy() , like the one fixed by b69c7c5dac.
I haven't yet encountered any overflow bugs in the wild along this
patch's codepath. But I recently solved, in commit b69c7c5dac, an overflow
bug in a line
Committed, with Cc stable tags in message.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 19/11/14 00:06, Chad Versace wrote:
> Fixes regression of WebGL Conformance test texture-size-limit [1] on
> Ivybridge Mobile GT2 0x0166 with Google Chrome R38.
>
> Regression introduced by
>
> commit 6c044231535b93c5d16404528946cad618d96bd9
> Author: Kenneth Graunke
> Date: Sun
Hi Iago,
On 18/11/14 08:43, Iago Toral Quiroga wrote:
[snip]
> Summary of the patches:
> * Patches 1-7 are general fixes to the current code that were found while
>working on this.
Have you noticed if any of those fixes resolves a piglit and/or a real
world application ? If so it might be wor
That's much simpler. :)
Reviewed-by: Ian Romanick
On 11/18/2014 04:06 PM, Chad Versace wrote:
> Fixes regression of WebGL Conformance test texture-size-limit [1] on
> Ivybridge Mobile GT2 0x0166 with Google Chrome R38.
>
> Regression introduced by
>
> commit 6c044231535b93c5d16404528946cad
Before we start discussing what we can do about the OpenGL API
overhead, we must get rid of the on-demand shader compilation. It's
unacceptable to compile shaders when we should be rendering. This is
one of the things that Nine fixes. I assume Wine does that because
there can be several slightly-di
On 18/11/14 07:46, Michel Dänzer wrote:
> On 18.11.2014 05:43, Emil Velikov wrote:
>> Hello all,
>>
>> As you may have noticed there are only three commits since 10.3.3, which
>> imho are quite serious of people hitting those issues.
>> Thus I do plan on releasing 10.3.4 this Friday.
>>
>> The usua
Fixes regression of WebGL Conformance test texture-size-limit [1] on
Ivybridge Mobile GT2 0x0166 with Google Chrome R38.
Regression introduced by
commit 6c044231535b93c5d16404528946cad618d96bd9
Author: Kenneth Graunke
Date: Sun Feb 2 02:58:42 2014 -0800
i965: Bump GL_MAX_C
On 18/11/14 18:36, Henri Verbeet wrote:
> On 17 November 2014 21:05, Emil Velikov wrote:
>> - GL extensions
>> I feel that it's a bit too much to shoot the project down, because it
>> does not introduce GL extensions that will be useful.
> To clarify, that's not what I said. It's mostly just that
Pushed. Thanks!
--Jason
On Sat, Nov 15, 2014 at 7:07 PM, Siavash Eliasi
wrote:
> Please push it, I don't have write access.
>
> Best regards,
> Siavash Eliasi.
>
>
> On 11/15/2014 11:06 PM, Jason Ekstrand wrote:
>
> Good catch!
>
> Reviewed-by: Jason Ekstrand
>
> Can you push or do you nee
https://bugs.freedesktop.org/show_bug.cgi?id=54080
Kaveh changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |n...@linux.intel.com
|org
On Tue 18 Nov 2014, Chris Forbes wrote:
Two things were broken here:
- The depth/stencil surface dimensions were broken for MSAA.
- Sample count was programmed incorrectly.
Result was the depth resolve didn't work correctly on MSAA surfaces, and
so sampling the surface later produced garbage.
F
From: Dave Airlie
The piglit tests were failing, and it appeared to be SB
optimising out things, but Glenn pointed out the gradients
are meant to be clause local, so we should emit the texture
instructions in the same clause. This moves things around
to always copy to a temp and then emit the tex
On Tue, Nov 18, 2014 at 1:42 PM, Jose Fonseca wrote:
> On 18/11/14 17:10, Jason Ekstrand wrote:
>
>> Jose,
>> I haven't had time to fully review Iago and Samuel's code, so I can't
>> 100% comment on it right now. However, let me make a few comments on
>> the "overarching plan" as it were.
>>
>>
From: Dave Airlie
The piglit tests were failing, and it appeared to be SB
optimising out things, but Glenn pointed out the gradients
are meant to be clause local, so we should emit the texture
instructions in the same clause. This moves things around
to always copy to a temp and then emit the tex
Hi Stefan,
On 18/11/14 21:21, Stefan Dösinger wrote:
> Am 2014-11-18 19:36, schrieb Henri Verbeet:
>> To clarify, that's not what I said. It's mostly just that I'd like
>> to see some actual evidence for the (implicit) claim that the
>> performance difference is largely due to inherent OpenGL API
On Tue, Nov 18, 2014 at 12:35 PM, Ben Widawsky
wrote:
> Add support for decoding the new branch control bit. I saw two things wrong
> with
> the existing code.
>
> 1. It didn't bother trying to decode the bit.
> - While we do not *intentionally* emit this bit today, I think it's
> interesting
>
On Tue, 18 Nov 2014 07:59:23 +0100, Dave Airlie wrote:
From: Dave Airlie
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
Fixes:
./bin/tex-miplevel-selection textureLodOffset 1DArray
./bin/tex-mi
On Tue, 18 Nov 2014 05:09:05 +0100, Dave Airlie wrote:
From: Dave Airlie
Otherwise we seem to lose the split_gs_inputs and try and
pull from an uninitialised register.
fixes 9 texelFetch geom shader tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 3 ++-
1 fi
Series LGTM.
Jose
On 18/11/14 22:05, srol...@vmware.com wrote:
From: Roland Scheidegger
No changes required in the driver itself, all handled by draw.
piglit results in a quick run:
skip->pass 7
skip->fail 2
(The new failures in the ARB_fragment_layer_viewport group are expected,
we fail the
From: Roland Scheidegger
Mostly add a couple cases so we don't just check gs for this.
There's only one gotcha, the built-in vp transform in the llvm vs can't
handle it (this would be fixable though non-trivial due to vp index being
non-constant for the SoA outputs, but we don't use it if there's
From: Roland Scheidegger
No changes required in the driver itself, all handled by draw.
piglit results in a quick run:
skip->pass 7
skip->fail 2
(The new failures in the ARB_fragment_layer_viewport group are expected,
we fail the same if gs doesn't write these outputs regardless of the vs.)
---
On 18/11/14 17:10, Jason Ekstrand wrote:
Jose,
I haven't had time to fully review Iago and Samuel's code, so I can't
100% comment on it right now. However, let me make a few comments on
the "overarching plan" as it were.
On Tue, Nov 18, 2014 at 2:36 AM, Jose Fonseca mailto:jfons...@vmware.com>>
Iago,
Most of this looks pretty good to me. The one primary concern I have is in
the handling of integer formats. I made the comment in a couple of
patches, but I'll make it in general here. In a lot of the code, when you
convert from integer formats to float, you treat them as if they are
norma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2014-11-18 19:36, schrieb Henri Verbeet:
> To clarify, that's not what I said. It's mostly just that I'd like
> to see some actual evidence for the (implicit) claim that the
> performance difference is largely due to inherent OpenGL API
> overhead.
Add support for decoding the new branch control bit. I saw two things wrong with
the existing code.
1. It didn't bother trying to decode the bit.
- While we do not *intentionally* emit this bit today, I think it's interesting
to see if we somehow ended up with the bit set. It may also be usefu
On Mon, Nov 3, 2014 at 4:23 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/main/uniform_query.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
> index
On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
wrote:
> From: Samuel Iglesias Gonsalvez
>
> This will be used to refactor code in pack.c and support conversion
> to/from these types in a master convert function that will be added
> later.
>
> Signed-off-by: Samuel Iglesias Gonsalvez
> --
On 2014-11-18 00:56:02, Kenneth Graunke wrote:
> On Tuesday, November 18, 2014 09:49:53 PM Chris Forbes wrote:
> > Two things were broken here:
> > - The depth/stencil surface dimensions were broken for MSAA.
> > - Sample count was programmed incorrectly.
> >
> > Result was the depth resolve didn'
Yeah, I understand this concern. But this could be said about any
uber-shader approach. For cases when one cannot afford to change
shader program in between draw calls (using features like multi draw
indirect), it should be better to use shader subroutine arrays instead
of a switch. If the differen
On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
wrote:
> From: Samuel Iglesias Gonsalvez
>
> Signed-off-by: Samuel Iglesias Gonsalvez
> ---
> src/mesa/main/format_pack.c.mako | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/format_pack.c.mak
Patches 12 and 13 are
Reviewed-by: Ian Roamnick
The other require_NV_fp opcodes can also be removed from
program_lexer.l. ir_to_mesa can generate those opcodes, but we can't
get them from an assembly source shader.
On 11/12/2014 05:18 PM, Eric Anholt wrote:
> The extension itself was deleted 2
On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
wrote:
> From: Samuel Iglesias Gonsalvez
>
> We will use this later on to handle uint conversion scenarios in a master
> convert function.
>
> Signed-off-by: Samuel Iglesias Gonsalvez
> ---
> src/mesa/main/format_pack.c.mako | 88
> +
On 11/18/2014 07:40 AM, Brian Paul wrote:
> Thanks for splitting up the patch. Your commit message below line wraps
> a bit short (~70 chars is about right). I'll fix that before pushing.
You can add
Reviewed-by: Ian Romanick
to patches 2 and 3 too.
> -Brian
>
>
> On 11/18/2014 06:49 AM, A
On Tue, Nov 18, 2014 at 12:43 AM, Iago Toral Quiroga
wrote:
> From: Jason Ekstrand
>
> We were auto-generating it before. The problem was that the autogeneration
> tool we were using was called "copy, paste, and edit". Let's use a more
> sensible solution.
>
> Signed-off-by: Jason Ekstrand
>
On 11/16/2014 08:31 AM, Gustaw Smolarczyk wrote:
> Hello once again,
>
> This time, I would like to ask about the shader subroutine extension.
> I believe this extension is not very popular, but is still needed for
> GL4 compliance.
>
> What is the reason for its unpopularity?
> Is it because one
On Tue, Nov 18, 2014 at 12:43 AM, Iago Toral Quiroga
wrote:
> From: Jason Ekstrand
>
> An array format is a 32-bit integer format identifier that can represent
> any format that can be represented as an array of standard GL datatypes.
> While the MESA_FORMAT enums provide several of these, they
On 17 November 2014 21:05, Emil Velikov wrote:
> - GL extensions
> I feel that it's a bit too much to shoot the project down, because it
> does not introduce GL extensions that will be useful.
To clarify, that's not what I said. It's mostly just that I'd like to
see some actual evidence for the (
In general, I like this patch. However, if we are going to claim to follow
the GL rule of "Colors are clampped to their representable range, then
there still seem to be quite a few cases missing. For instance, when going
from signed to unsigned 8-bit formats, we should should take a min with 0
an
On 11/17/2014 01:42 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 10.4
> ---
> src/gallium/drivers/radeonsi/si_state_draw.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
> b/src/gallium/dr
On 11/14/2014 07:07 AM, Erik Faye-Lund wrote:
> On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov
> wrote:
>> Hello all,
>>
>> This is an old question that I had laying around - why doesn't mesa use
>> a more conventional numbering for the development/rc releases ?
>>
>> Eg.
>> mesa 10.4.0-rc1 -> 10.
Jose,
I haven't had time to fully review Iago and Samuel's code, so I can't 100%
comment on it right now. However, let me make a few comments on the
"overarching plan" as it were.
On Tue, Nov 18, 2014 at 2:36 AM, Jose Fonseca wrote:
> > The idea is that we have a lot of format conversion code s
ping
On Mon, 2014-11-03 at 20:29 -0500, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
>
> moreover, the condition is never true now that clover appends dim info
>
> src/gallium/drivers/r600/evergreen_compute.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/src/gallium/drive
Thanks for splitting up the patch. Your commit message below line wraps
a bit short (~70 chars is about right). I'll fix that before pushing.
-Brian
On 11/18/2014 06:49 AM, Andres Gomez wrote:
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
seg
On Tue, Nov 18, 2014 at 9:53 AM, Jose Fonseca wrote:
> On 18/11/14 14:34, Roland Scheidegger wrote:
>>
>> Am 18.11.2014 um 15:05 schrieb Ilia Mirkin:
>>>
>>> On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger
>>> wrote:
Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
>
> For values
On 11/18/2014 02:23 AM, Iago Toral Quiroga wrote:
From: Samuel Iglesias Gonsalvez
This covers glGetTexImage for uncompressed color formats.
Signed-off-by: Samuel Iglesias Gonsalvez
Signed-off-by: Eduardo Lima Mitev
---
src/mesa/main/texgetimage.c | 170 ++---
On 18/11/14 14:34, Roland Scheidegger wrote:
Am 18.11.2014 um 15:05 schrieb Ilia Mirkin:
On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger wrote:
Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
For values above integer accuracy in floats, val - floor(val) might
actually produce a value greater
Am 18.11.2014 um 15:05 schrieb Ilia Mirkin:
> On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger
> wrote:
>> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
>>> For values above integer accuracy in floats, val - floor(val) might
>>> actually produce a value greater than 1. For such large floats, it'
On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger wrote:
> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
>> For values above integer accuracy in floats, val - floor(val) might
>> actually produce a value greater than 1. For such large floats, it's
>> reasonable to be imprecise, but it's unreasonab
Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
> For values above integer accuracy in floats, val - floor(val) might
> actually produce a value greater than 1. For such large floats, it's
> reasonable to be imprecise, but it's unreasonable for FRC to return a
> value that is not between 0 and 1.
>
>
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding hash tables are
not included in the shader program. Obviously, we
cannot make the linking stage succeed without the
bound attributes but we can prevent the crash and
jus
---
src/glsl/linker.cpp | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 2d31801..794efdc 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -642,7 +642,7 @@ validate_geometry_s
---
src/gallium/auxiliary/draw/draw_private.h | 2 +-
src/gallium/auxiliary/draw/draw_pt_vsplit.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_private.h
b/src/gallium/auxiliary/draw/draw_private.h
index d8dc2ab..37045eb 100644
--- a/src/
On Mon, 2014-11-17 at 09:25 -0700, Brian Paul wrote:
> Please split up this patch into:
>
> 1. gallium comment fixes
> 2. linker string fixes
> 3. hash table code changes
Sure. I thought it was not worth given the small changes but I suppose
it is always better to have different topics in differe
Signed-off-by: Timothy Arceri
---
src/util/hash_table.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/util/hash_table.c b/src/util/hash_table.c
index 1b6726c..920bdfd 100644
--- a/src/util/hash_table.c
+++ b/src/util/hash_table.c
@@ -385,12 +385,12 @@ _mesa_ha
> The idea is that we have a lot of format conversion code scattered
through
> different files in the repository, a lot of that is redundant /
duplicated,
> so this intends to address that issue.
First, I think this is a great goal. And while I haven't reviewed them
in detail, just from skimm
I forgot to say that the series is available for testing here:
https://github.com/Igalia/mesa/tree/itoral-autogen-packing-review
Also, one of the patches was held for review by the list owner due to
its size (patch 12, which handles auto-generation of format_unpack.c),
so reviewers can fetch it fr
Both glReadPixels and glGetTexImage have RGBA rebasing logic that is almost
the same, so move that logic to a separate helper function
_mesa_get_rebase_format_for_color_read_back and call this from
both implementations.
---
src/mesa/main/pack.c| 69 +
From: Jason Ekstrand
v2 by Iago Toral :
- When testing if we can directly pack we should use the src format to check
if we are packing from an RGBA format. The original code used the dst format
for the ubyte case by mistake.
- Fixed incorrect number of bits for dst, it was computed using the
From: Eduardo Lima Mitev
_mesa_unpack_bitmap() was introduced by commit 02b801c to handle the case
when data is stored in PBO by display lists, in the context of this bug:
Incorrect pixels read back if draw bitmap texture through Display list
https://bugs.freedesktop.org/show_bug.cgi?id=10370
S
We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
functions receive an extra parameter so we can swap bytes on a source
input array and store the results in a (possibly different) destination
array.
This is useful to implement byte-swapping in pixel uploads, since in this
c
This is necessary to handle conversions between array types where
the driver does not support the dst format requested by the client and
chooses a different format instead.
We will need this in _mesa_format_convert, so move it to format_utils.c,
prefix it with '_mesa_' and make it available to oth
Notice that _mesa_format_convert does not handle byte-swapping scenarios,
GL_COLOR_INDEX or MESA_FORMAT_YCBCR(_REV), so these must be handled
separately.
Also, remove all the code that goes unused after using _mesa_format_convert.
---
src/mesa/main/texstore.c | 676 +--
This is no longer used.
---
src/mesa/main/pack.c | 646 ---
src/mesa/main/pack.h | 6 -
2 files changed, 652 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index afc168c..46b103e 100644
--- a/src/mesa/main/pack.c
+++ b/src/m
This is the only place that uses _mesa_unpack_color_span_float so after
this we will be able to remove it.
---
src/mesa/swrast/s_drawpix.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/src/mesa/swrast/s_drawpix.c b/src/mesa/swrast/s_dr
Now that we have _mesa_format_convert we don't need this.
texstore_rgba will use the GL_COLOR_INDEX to RGBA conversion
helpers instead and compressed formats that used
_mesa_make_temp_ubyte_image to create an ubyte RGBA temporary
image can call _mesa_texstore with a RGBA/ubyte dst to
achieve the s
Now that we have _mesa_format_convert we don't need this.
This was only used to create temporary RGBA float images in the process
of storing some compressed formats. These can call _mesa_texstore
with a RGBA/float dst to achieve the same goal.
---
src/mesa/main/texcompress_bptc.c | 20 +++---
sr
And various helper functions that went unused after removing it.
---
src/mesa/main/pack.c | 1033 --
src/mesa/main/pack.h |9 -
2 files changed, 1042 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index 0d77c4e..e45bfb1 10
These are no longer used now that we moved to _mesa_format_convert.
---
src/mesa/main/pack.c | 225 ---
src/mesa/main/pack.h | 12 ---
2 files changed, 237 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index d89fc7b..0d77c4e
_mesa_pack_rgba_span_float was the last of the color span functions
and we have replaced all calls to it with calls to _mesa_format_convert,
so we can remove it together with tmp_pack.h which was used to
generate the pack functions for multiple types that were used from
the various color span funct
A direct unpack to this format from a signed format won't clamp so we should
not resolve converts of this kind via the unpack fast path. These scenarios
will be handled properly by mesa_swizzle_and_convert path.
---
src/mesa/main/format_utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
From: Samuel Iglesias Gonsalvez
This covers glGetTexImage for uncompressed color formats.
Signed-off-by: Samuel Iglesias Gonsalvez
Signed-off-by: Eduardo Lima Mitev
---
src/mesa/main/texgetimage.c | 170 ++--
1 file changed, 117 insertions(+), 53 deleti
We can have conversions from non-integer types to integer types, so remove
the assertions for these in the pack/unpack fast paths. It could be that
we do not have all the necessary pack/unpack functions in these cases though,
so protect these paths with conditionals and let _mesa_format_convert use
From: Samuel Iglesias Gonsalvez
We had previously added the needed mesa formats, so we can simplify
the code further.
Signed-off-by: Samuel Iglesias Gonsalvez
---
src/mesa/main/pack.c | 282 +--
1 file changed, 26 insertions(+), 256 deletions(-)
For glReadPixels with a Luminance destination format we compute luminance
values from RGBA as L=R+G+B. This, however, requires ad-hoc implementation,
since pack/unpack functions or _mesa_swizzle_and_convert won't do this
(and thus, neither will _mesa_format_convert). This patch adds helpers
to do t
In order to check if a format is normalized Mesa does something like this:
normalized = !_mesa_is_enum_format_integer(srcFormat);
So all float types will set normalized to true. Since our mesa_array_format
includes a normalized flag for each type we want to make it consistent with
this.
---
src/m
When we needed the base format for a mesa_array_format we had to find
the matching mesa_format first. This is expensive because it requires
to loop through all existing mesa formats until we find the right match.
We can resolve the base format of an array format directly by looking
at its swizzle
From: Samuel Iglesias Gonsalvez
These are no longer used.
Signed-off-by: Samuel Iglesias Gonsalvez
---
src/mesa/main/format_pack.c.mako | 121 ---
src/mesa/main/format_pack.h | 4 --
2 files changed, 125 deletions(-)
diff --git a/src/mesa/main/format
This is no longer used anywhere after moving to _mesa_format_convert.
---
src/mesa/main/pack.c | 256 ---
src/mesa/main/pack.h | 9 --
2 files changed, 265 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index 46b103e..d89fc7
This replaces all remaining uses of this function, which will be
removed in another commit.
---
src/mesa/main/texgetimage.c| 23 +++
src/mesa/state_tracker/st_cb_texture.c | 14 ++
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/src/mesa
These are not used anywhere.
---
src/mesa/main/pack.c | 219 ---
src/mesa/main/pack.h | 15
2 files changed, 234 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index 49b2998..a804a58 100644
--- a/src/mesa/main/pack.c
+++
This is the second of two series of patches to address:
https://bugs.freedesktop.org/show_bug.cgi?id=84566
This series is based on the previous series we sent for review: Auto-generate
pack/unpack functions. To ease review and testing, the combined series are
available here:
https://github.com/Ig
We only use _mesa_make_temp_ubyte_image in texstore.c to convert
GL_COLOR_INDEX to RGBA, but this helper does more stuff than this.
All uses of this helper can be replaced with calls to
_mesa_format_convert except for this GL_COLOR_INDEX conversion.
This patch extracts the GL_COLOR_INDEX to RGBA l
In general, if the dst base internal format and the selected dst format are
different we can't be sure that directly packing or unpacking to the destination
format will produce correct results. In these cases we probably want to fall
back to other paths (like mesa_swizzle_and_convert) that can hand
1 - 100 of 128 matches
Mail list logo
