On Sat, Mar 29, 2014 at 7:14 PM, Eric Anholt wrote:
> Matt Turner writes:
>
>> Otherwise calling dump_instructions() after declaring a new fs_reg would
>> segfault when calculate_register_pressure()'s loop over reg walked off
>> the end of the virtual_grf_start[] array that calculate_live_interva
This should provide reasonable behavior for those paths too -- the
combination of these two patches preserves the current behavior for
st_choose_matching_format. It's not quite ideal (I believe actual use
of intensity formats in some situations will miss the fast path), but
it's no worse.
I'm not
Matt Turner writes:
> Otherwise calling dump_instructions() after declaring a new fs_reg would
> segfault when calculate_register_pressure()'s loop over reg walked off
> the end of the virtual_grf_start[] array that calculate_live_intervals()
> would have reallocated for you, if it had known ther
However st_choose_matching_format is also used by other clients such
as TexImage, GetTexImage, and ReadPixels, so this should really be
fixed in the problematic caller of st_choose_matching_format, that is
DrawPixels.
Marek
On Sat, Mar 29, 2014 at 7:48 PM, Chris Forbes wrote:
> On Sun, Mar 30, 2
Previously we'd ignore the sources of instructions with non-GRF
destinations when calculating calculating the dead channels. This would
lead to us incorrectly removing the first instruction in this sequence:
mov vgrf11, ...
cmp.ne.f0 null, vgrf11, 1.0
mov vgrf11, ...
Bugzilla: https://bu
On Sun, Mar 30, 2014 at 12:50 AM, Marek Olšák wrote:
> Why is this needed?
The second patch fixes format/type to mesa_format matching for
intensity formats, so that texture uploads / buffer object clears /
etc can get the memcpy paths. (Previously, we were testing on pixel
format = GL_INTENSITY,
On Sat, Mar 29, 2014 at 5:23 AM, Emil Velikov wrote:
> Both "issues" were in the original code. But if you feel so strongly about
> them I will have them changed for rev2 of the series.
I mean, you're modifying the lines now, so just squash in a fixup and
be done with it? I don't think there's an
Hi Emil,
Emil Velikov schrieb am 29.03.2014 14:21:
> On 29/03/14 12:37, Kai Wasserbäch wrote:
>> I saw one of your patches currently in review touching the Makefile.am of
>> libxatracker. Can you squeeze in another patch, that ensures, that the
>> library
>> only exports its own symbols and not th
On 28/03/14 21:48, Matt Turner wrote:
> On Thu, Mar 27, 2014 at 2:00 PM, Emil Velikov
> wrote:
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/targets/pipe-loader/Makefile.am | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/targets/pipe-loader/M
On 28/03/14 21:40, Matt Turner wrote:
> On Thu, Mar 27, 2014 at 2:00 PM, Emil Velikov
> wrote:
>> We've been copying and pasting this hunk for a while now, only to prevent
>> build issues on very old and buggy build toolchains. At this point this
>> should no longer be needed, so we can cleanup a
On 28/03/14 21:34, Matt Turner wrote:
> On Thu, Mar 27, 2014 at 2:00 PM, Emil Velikov
> wrote:
>> Cc: Christian König
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/Automake.inc | 6 ++
>> src/gallium/targets/r600/omx/Makefile.am | 5 +
>> src/gallium/targ
On 28/03/14 21:32, Matt Turner wrote:
> On Thu, Mar 27, 2014 at 2:00 PM, Emil Velikov
> wrote:
>> This lets us have only one if HAVE_MESA_LLVM block, rather than
>> one for each driver.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/targets/pipe-loader/Makefile.am | 34
>> ++--
On 28/03/14 21:25, Matt Turner wrote:
> On Thu, Mar 27, 2014 at 2:00 PM, Emil Velikov
> wrote:
>> Mesa does _not_ against libudev.
>
> I think you a word. :)
>
Nice one thanks. :D
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.f
On 28/03/14 21:21, Matt Turner wrote:
> On Thu, Mar 27, 2014 at 2:00 PM, Emil Velikov
> wrote:
>> Evidently at least static OSMesa is still used as shared one
>> causes substantial increase in the load time for some programs
>> that use it (from seconds up-to ~30min).
>>
>> Rather than forcing ev
On Sat, Mar 29, 2014 at 12:02 AM, Chris Forbes wrote:
> _mesa_format_matches_format_and_type() returns true for
> GL_RED/GL_RED_INTEGER (with an appropriate type) into an intensity
> mesa_format.
>
> We want the `red`-based format instead, regardless of the order we find
> them in our walk of the
On 03/28/2014 05:02 PM, Chris Forbes wrote:
_mesa_format_matches_format_and_type() returns true for
GL_RED/GL_RED_INTEGER (with an appropriate type) into an intensity
mesa_format.
We want the `red`-based format instead, regardless of the order we find
them in our walk of the mesa formats list.
On 03/28/2014 09:56 PM, Chris Forbes wrote:
The case for this was in the wrong function, and this format's store
func was not set in the table at all.
Signed-off-by: Chris Forbes
---
src/mesa/main/texstore.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/m
17 matches
Mail list logo
