For example if width were 65, the first slice would get 96 while the
second would get 32. However the hardware appears to expect the second
pitch to be 64, based on halving the 96 (and aligning up to 32).
This fixes texelFetch piglit tests on a3xx.
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.5"
---
On Fri, Mar 13, 2015 at 12:46 AM, Matt Turner wrote:
> Here are some ideas I think might be reasonable GSoC ideas.
>
> - GLSL linking in NIR
> - Would allow us to stop doing optimizations and other expensive
> things on GLSL IR
>
> - SSA in the i965/fs backend, and an SSA-based register all
On Thu, Mar 12, 2015 at 9:24 PM, Jason Ekstrand
wrote:
> Sean,
> I got ready to push this and ran it against piglit and one of the tests
> errored out. Looking into it further, it was a bug in the test. I've sent
> a patch:
>
> http://lists.freedesktop.org/archives/piglit/2015-March/015156.html
We only program in one layer size per texture, so that means that all
levels must share one size. This makes the piglit test
bin/texelFetch fs sampler2DArray
have the same breakage as its non-array version instead of being
completely off.
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.5"
---
Need to
Here are some ideas I think might be reasonable GSoC ideas.
- GLSL linking in NIR
- Would allow us to stop doing optimizations and other expensive
things on GLSL IR
- SSA in the i965/fs backend, and an SSA-based register allocator
- Improve instruction scheduling in i965 (Nouveau has thi
Sean,
I got ready to push this and ran it against piglit and one of the tests
errored out. Looking into it further, it was a bug in the test. I've sent
a patch:
http://lists.freedesktop.org/archives/piglit/2015-March/015156.html
I'll merge the mesa commit once we get piglit fixed.
--Jason
On T
On 13.03.2015 03:07, Pierre-Loup A. Griffais wrote:
> On 03/11/2015 09:40 AM, Ian Romanick wrote:
>> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>>> The problem in not forcing this to link statically is, that if a
>>> distribution decides to not use this static option, the problem persists
>>>
On Tue, Mar 3, 2015 at 11:43 AM, Alexander Mezin
wrote:
> Hello.
>
> I plan to participate in GSoC this year as a student. And I've found a
> project idea which I like very much on X.Org's ideas page. It's called
> "Improved application of GLSL compiler optimizations".
>
> For me, it looks mostly
On Thu, Mar 12, 2015 at 3:53 PM, Carl Worth wrote:
> On Thu, Mar 12 2015, Matt Turner wrote:
>> I think you misread. rint() *does* provide the behavior we want
>> (round-to-nearest, half to even) when the rounding mode is the default
>> round-to-nearest.
>
> Thanks. I did at least verify that beha
Fix typo in comment introduced by 70dc8a
Signed-off-by: Alexandre Demers
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index d60d
Am 12.03.2015 um 23:53 schrieb Carl Worth:
> On Thu, Mar 12 2015, Matt Turner wrote:
>> I think you misread. rint() *does* provide the behavior we want
>> (round-to-nearest, half to even) when the rounding mode is the default
>> round-to-nearest.
>
> Thanks. I did at least verify that behaviorally
On 03/12/2015 04:34 PM, Mario Kleiner wrote:
glXGetProcAddress("glFoo") ends up in stub_add_dynamic() to
create dynamic stubs for dynamic functions. stub_add_dynamic()
doesn't store the caller provided name string "Foo" in a mesa
private copy, but just stores a pointer to the "glFoo" string
passe
Jason,
No worries. It looks like my mail client munged the patch in some way.
I'm sending it as an attachment in the hopes that it will remain
untouched.
Sean Burke
On Wed, Mar 11, 2015 at 2:53 PM, Jason Ekstrand wrote:
> Sean,
> Sorry it's taken so long for me to get to this, but I went to te
On 03/12/2015 05:03 PM, Matt Turner wrote:
On Thu, Mar 12, 2015 at 2:54 PM, Brian Paul wrote:
---
src/gallium/auxiliary/util/u_slab.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_slab.h
b/src/gallium/auxiliary/util/u_slab.h
On Thu, Mar 12, 2015 at 2:54 PM, Brian Paul wrote:
> ---
> src/gallium/auxiliary/util/u_slab.h | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_slab.h
> b/src/gallium/auxiliary/util/u_slab.h
> index 29d0252..8f8b29b 100644
> ---
On Thu, Mar 12 2015, Matt Turner wrote:
> I think you misread. rint() *does* provide the behavior we want
> (round-to-nearest, half to even) when the rounding mode is the default
> round-to-nearest.
Thanks. I did at least verify that behaviorally as I just mentioned in a
separate mail.
> As Eric
On 03/11/2015 05:36 AM, Chris Wilson wrote:
> Currently, we throttle before the user begins preparing commands for the
> next frame when we acquire the draw/read buffers. However, construction
> of the command buffer can itself take significant time relative to the
> frame time. If we move the thro
On 03/10/2015 09:15 PM, Matt Turner wrote:
> On Tue, Mar 10, 2015 at 8:19 PM, Ian Romanick wrote:
>> On 03/10/2015 05:20 PM, Matt Turner wrote:
>>> Creating/recreating the strings in eglQueryString() is extra work and
>>> isn't thread-safe, as exhibited by shader-db's run.c using libepoxy.
>>>
>>>
glXGetProcAddress("glFoo") ends up in stub_add_dynamic() to
create dynamic stubs for dynamic functions. stub_add_dynamic()
doesn't store the caller provided name string "Foo" in a mesa
private copy, but just stores a pointer to the "glFoo" string
passed to glXGetProcAddress - a pointer into arbitra
On Thu, Mar 12, 2015 at 2:59 PM, Carl Worth wrote:
> On Thu, Mar 12 2015, Matt Turner wrote:
>> +/* The C standard library has functions round()/rint()/nearbyint() that
>> round
>> + * their arguments according to the rounding mode set in the floating-point
>> + * control register. While there ar
On Thu, Mar 12 2015, Carl Worth wrote:
> But beyond that, I'm actually confused---how can the default rounding
> mode (rounding toward nearest number, right?) give us an adequate
> implementation for roundeven()?
Of course, I had asked for (and received) a patch with a test. And the
test verifies
https://bugs.freedesktop.org/show_bug.cgi?id=89563
MichaelJ changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, Mar 12 2015, Matt Turner wrote:
> +/* The C standard library has functions round()/rint()/nearbyint() that round
> + * their arguments according to the rounding mode set in the floating-point
> + * control register. While there are trunc()/ceil()/floor() functions that do
> + * a specific o
---
src/gallium/auxiliary/util/u_slab.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_slab.h
b/src/gallium/auxiliary/util/u_slab.h
index 29d0252..8f8b29b 100644
--- a/src/gallium/auxiliary/util/u_slab.h
+++ b/src/gallium/auxiliary/
https://bugs.freedesktop.org/show_bug.cgi?id=89563
--- Comment #3 from Matt Turner ---
This sounds to me like you have 1.9 with some patches applied. If that's the
case, configure is rightly failing.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=89563
--- Comment #2 from MichaelJ ---
Response for this command is 1.9
Yum reports package 1.9-5.el7. this is latest available for my yum
repositories.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=89563
--- Comment #1 from Jan Vesely ---
(In reply to MichaelJ from comment #0)
> Incorrect error message "DRI3 requires xcb >= 1.9.3" when installed version
> of libxcb is 1.9-5, later then 1.9.3.
> "libxcb -v" returns 1.9-5.el7 but is parsed by conf
On Thu, Mar 12, 2015 at 1:11 PM, Ilia Mirkin wrote:
> On Thu, Mar 12, 2015 at 3:11 PM, Matt Turner wrote:
>> The SSE 4.1 ROUND instructions let us implement roundeven directly.
>> Otherwise we assume that the rounding mode has not been modified (as we
>> do in the rest of Mesa) and use rint().
>>
https://bugs.freedesktop.org/show_bug.cgi?id=89563
Bug ID: 89563
Summary: Bug in configure verifying xcb version
Product: Mesa
Version: 10.5
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: n
That's okay, just wanted to make sure that 10.5 was correct.
On Thu, Mar 12, 2015 at 1:49 PM, Emil Velikov
wrote:
> On 12/03/15 16:55, Laura Ekstrand wrote:
> > Emil,
> >
> > I spoke with Neil Roberts, and the two patches of mine you have listed
> > as rejected here are required basis for his fo
On 12/03/15 16:55, Laura Ekstrand wrote:
> Emil,
>
> I spoke with Neil Roberts, and the two patches of mine you have listed
> as rejected here are required basis for his four queued commits (all of
> these pertain to meta_pbo_texSubImage). The only patch that was
> reverted was my "1D ARRAY" patc
On Thu, Mar 12, 2015 at 3:11 PM, Matt Turner wrote:
> The SSE 4.1 ROUND instructions let us implement roundeven directly.
> Otherwise we assume that the rounding mode has not been modified (as we
> do in the rest of Mesa) and use rint().
>
> glibc uses the ROUND instruction in rint() after a cpuid
It appears that our Piglit tests that hit glGenerateMipmap always create
the cube map texture with Texture Storage, so Num Layers always gets set to
6. I will make a simple test this afternoon for non texture storage cube
maps.
On Mar 12, 2015 12:33 PM, "Laura Ekstrand" wrote:
> This reverts com
Hi all,
a respin of the bugfix for INTEL_swap_events + DRI3/Present.
The code in the patch itself is identical to the one queued
for Mesa 10.5.1, the one apparently nobody wants to review
- I hate wraparound handling too...
The only difference is a much longer commit message which
explains why w
The code for emitting INTEL_swap_events swap completion
events needs to translate from 32-Bit sbc on the wire to
64-Bit sbc for the events and handle wraparound accordingly.
It assumed that events would be sent by the server in the
order their corresponding swap requests were emitted from
the clie
This reverts commit 1ee000a0b6737d6c140d4f07b6044908b8ebfdc7.
Failures with the GLES3 conformance suite and Synmark2 OGLHdrBloom revealed
that this commit might be in error. A look at the offended test in GLES3
conformance suite, NPOT gen mipmap, suggests that NumLayers may not actually
always be
On 03/11/2015 04:10 PM, Matt Turner wrote:
> On Wed, Mar 11, 2015 at 1:44 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> At the very least, unreal4/sun-temple/102.shader_test uses this pattern
>> for a signed integer result. However, that shader did not hit the
>> optimization in the first
The SSE 4.1 ROUND instructions let us implement roundeven directly.
Otherwise we assume that the rounding mode has not been modified (as we
do in the rest of Mesa) and use rint().
glibc uses the ROUND instruction in rint() after a cpuid check. This
patch just lets us inline it directly when we're
On Wed, Mar 11, 2015 at 3:34 PM, Carl Worth wrote:
> So I think I'd like to see at least three or four commits here:
>
> 1. Change _mesa_round_to_even to return a float
I don't think this is really meaningful as a separate change. The
current _mesa_round_to_even function uses IROUND() whi
---
src/util/Makefile.am | 4 +-
src/util/roundeven_test.c | 140 ++
2 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644 src/util/roundeven_test.c
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index ec49dc6..2e7542e 1
Eric's initial patch adding constant expression evaluation for
ir_unop_round_even used nearbyint. The open-coded _mesa_round_to_even
implementation came about without much explanation after a reviewer
asked whether nearbyint depended on the application not modifying the
rounding mode. Of course (as
On Wed, Mar 11, 2015 at 09:10:01AM -0700, Ian Romanick wrote:
> On 03/06/2015 06:30 AM, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:38:44PM -0800, Ian Romanick wrote:
> >> On 03/04/2015 10:28 AM, Chad Versace wrote:
> >>> That text does not appear in the GL spec. When I read the manpage
>
On 03/11/2015 09:40 AM, Ian Romanick wrote:
On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
The problem in not forcing this to link statically is, that if a
distribution decides to not use this static option, the problem persists
on that distribution. On top every lib pulled in by steam from the
On 12/03/15 18:07, Sedat Dilek wrote:
On Fri, Mar 6, 2015 at 8:06 PM, Emil Velikov wrote:
On 4 March 2015 at 18:07, Roland Scheidegger wrote:
Am 04.03.2015 um 12:38 schrieb Jose Fonseca:
On 04/03/15 02:00, Emil Velikov wrote:
On 27 February 2015 at 23:28, Sedat Dilek wrote:
On Mon, Feb 9,
On Fri, Feb 27, 2015 at 05:34:54PM +0200, Francisco Jerez wrote:
> ---
> src/mesa/drivers/dri/i965/brw_defines.h| 1 +
> src/mesa/drivers/dri/i965/brw_eu.h | 7 +++
> src/mesa/drivers/dri/i965/brw_eu_emit.c| 51
> ++
> src/mesa/drivers
On Thu, Mar 12, 2015 at 07:25:34PM +0200, Francisco Jerez wrote:
> "Pohjolainen, Topi" writes:
>
> > On Fri, Feb 27, 2015 at 05:34:48PM +0200, Francisco Jerez wrote:
> >> Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
> >> surface index as a register instead of a constant
"Pohjolainen, Topi" writes:
> On Fri, Feb 27, 2015 at 05:34:48PM +0200, Francisco Jerez wrote:
>> Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
>> surface index as a register instead of a constant and to use
>> brw_send_indirect_message() to emit the indirect variant of s
"Pohjolainen, Topi" writes:
> On Fri, Feb 27, 2015 at 05:34:48PM +0200, Francisco Jerez wrote:
>> Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
>> surface index as a register instead of a constant and to use
>> brw_send_indirect_message() to emit the indirect variant of s
On Fri, Mar 06, 2015 at 02:56:24PM +0200, Francisco Jerez wrote:
> "Pohjolainen, Topi" writes:
>
> > On Fri, Feb 27, 2015 at 05:34:47PM +0200, Francisco Jerez wrote:
> >> This is currently not a problem because the vec4 visitor happens to
> >> mask out unused components from the destination, but
On Thu, Mar 12, 2015 at 12:14 AM, Eduardo Lima Mitev
wrote:
> Internal PBO functions such as _mesa_map_validate_pbo_source() and
> _mesa_validate_pbo_compressed_teximage() perform validation and buffer
> mapping
> within the same call.
>
> This patch takes out the validation into separate functio
On Fri, Feb 27, 2015 at 05:34:47PM +0200, Francisco Jerez wrote:
> This is currently not a problem because the vec4 visitor happens to
> mask out unused components from the destination, but it might become
> an issue when we start using atomics without writeback message. In
> any case it seems sen
On Fri, Feb 27, 2015 at 05:34:48PM +0200, Francisco Jerez wrote:
> Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
> surface index as a register instead of a constant and to use
> brw_send_indirect_message() to emit the indirect variant of send with
> a dynamically calculated
Emil,
I spoke with Neil Roberts, and the two patches of mine you have listed as
rejected here are required basis for his four queued commits (all of these
pertain to meta_pbo_texSubImage). The only patch that was reverted was my
"1D ARRAY" patch.
Laura
On Thu, Mar 12, 2015 at 6:50 AM, Emil Veli
On Fri, Feb 27, 2015 at 05:34:48PM +0200, Francisco Jerez wrote:
> Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
> surface index as a register instead of a constant and to use
> brw_send_indirect_message() to emit the indirect variant of send with
> a dynamically calculated
https://bugs.freedesktop.org/show_bug.cgi?id=89562
Bug ID: 89562
Summary: glXSwapIntervalMESA crashes when making use of
GLX_MESA_multithread_makecurrent
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
O
On Thu, Mar 12, 2015 at 7:10 AM, Francisco Jerez wrote:
> Meh, I've modified PATCH 01 so it drops the send destination type
> changes in the Gen7 pull constant load code (see attachment).
>
> Do we know if the destination type of the SEND instruction has any other
> subtle effects, like, affecting
On Sat, Feb 28, 2015 at 9:19 PM, Matt Turner wrote:
> On Sat, Feb 28, 2015 at 11:47 AM, Thomas Helland
> wrote:
>> On Feb 28, 2015 8:39 PM, "Jason Ekstrand" wrote:
>>>
>>> Both patches are
>>>
>>> Reviewed-by: Jason Ekstrand
>>
>> Could you commit them?
>> I don't have commit access.
>
> I'd li
Michel Dänzer wrote on 12.03.2015 08:15:
> On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
>> Hi - As you probably already know, there can only be one version of
>> libstdc++.so in your runtime link chain - This is usually not a problem,
>> but when things are linked against the Steam runtime (for e
On 03/12/2015 04:41 AM, Jose Fonseca wrote:
On 11/03/15 16:48, Brian Paul wrote:
v2: Use #error in the #else clause, per Jose.
---
include/c99_math.h | 44 ++
src/mesa/main/querymatrix.c | 51
+
2 files
eglcurrent.c: In function '_eglSetTSD':
eglcurrent.c:57:4: warning: passing argument 2 of 'tss_set' discards
'const' qualifier from pointer target type [enabled by default]
tss_set(_egl_TSD, (const void *) t);
^
In file included from ../../../include/c11/threads.h:72:0,
fro
Francisco Jerez writes:
> Matt Turner writes:
>
>> On Wed, Mar 11, 2015 at 2:29 PM, Francisco Jerez
>> wrote:
>>> Matt Turner writes:
commit 4c4934636cb286e7d7836afc26e9d392e2f0f155
Author: Paul Berry
Date: Tue Sep 24 15:18:52 2013 -0700
i965/blorp: retype dest
https://bugs.freedesktop.org/show_bug.cgi?id=89553
Brian Paul changed:
What|Removed |Added
Component|Mesa core |New Accounts
Assignee|mesa-dev@li
Hello list,
The candidate for the Mesa 10.5.1 is now available. The current patch queue
is as follows:
- 57 queued
- 3 nominated (outstanding)
- and 2 rejected (obsolete) patches
This provides us with over a dozen i965 fixes for all over the driver, some
r300g ones (correct handling of RGTC1 a
"Pohjolainen, Topi" writes:
> On Tue, Mar 10, 2015 at 11:07:26PM +0200, Francisco Jerez wrote:
>> "Pohjolainen, Topi" writes:
>>
>> > On Mon, Mar 09, 2015 at 12:43:08PM +0200, Francisco Jerez wrote:
>> >> "Pohjolainen, Topi" writes:
>> >>
>> >> > On Sat, Mar 07, 2015 at 04:15:08PM +0200, Fran
On 11/03/15 16:48, Brian Paul wrote:
v2: Use #error in the #else clause, per Jose.
---
include/c99_math.h | 44 ++
src/mesa/main/querymatrix.c | 51 +
2 files changed, 45 insertions(+), 50 deletions(-)
d
On 12/03/15 00:07, Emil Velikov wrote:
On 9 March 2015 at 11:54, Jose Fonseca wrote:
On 07/03/15 19:38, Emil Velikov wrote:
On 07/03/15 07:23, Jose Fonseca wrote:
...
we still
didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
tree gave me pause.
The only way I can thi
https://bugs.freedesktop.org/show_bug.cgi?id=89387
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Mar 11, 2015 at 2:09 PM, Ilia Mirkin wrote:
> On Wed, Mar 11, 2015 at 5:57 PM, wrote:
>> From: Marius Predut
>
> Set your email from name correctly in git and then you won't have this
> line in your git send-email results.
>
>>
>> On SNB and IVB hw, for 1 pixel line thickness or less,
>
Thanks. I noticed this too, but was too busy to fix it.
For the series:
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 12, 2015 at 2:45 AM, Matt Turner wrote:
> ARB_shading_language_packing is part of GLSL 4.2, not 4.0 as I
> mistakenly believed. The following functions are available only with
>
On Wed, Mar 11, 2015 at 1:07 PM, Kenneth Graunke wrote:
> On Wednesday, March 11, 2015 07:25:14 PM Francisco Jerez wrote:
>> "Pohjolainen, Topi" writes:
>> > On Fri, Feb 27, 2015 at 05:34:44PM +0200, Francisco Jerez wrote:
>> >> @@ -1218,17 +1198,6 @@
>> >> fs_generator::generate_varying_pull_co
On Wednesday, March 11, 2015 10:44:26 AM Pohjolainen, Topi wrote:
> On Mon, Mar 09, 2015 at 01:58:51AM -0700, Kenneth Graunke wrote:
> > The NIR backend hardcodes brw_wm_prog_key at the moment, which won't
> > work when we support scalar VS. We could use get_tex(), but it's a
> > static method. I
On 03/11/2015 10:44 PM, Ian Romanick wrote:
From: Ian Romanick
The ir_unop_any problem was discovered by some later optimization passes
that generate ir_triop_csel. I was also able to reproduce it by
modifying the gl-2.0-vertexattribpointer vertex shader to generate its
result using
color
"Pohjolainen, Topi" writes:
> On Fri, Feb 27, 2015 at 05:34:44PM +0200, Francisco Jerez wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_eu.h | 19 ++--
>> src/mesa/drivers/dri/i965/brw_eu_emit.c | 58
>> ++--
>> src/mesa/drivers/dri/i965/brw_fs_gene
Given the age of this bug, should this be a candidate for 10.4 and 10.5
stable branches?
On 03/10/2015 03:36 AM, Iago Toral Quiroga wrote:
> The piglit test glsl-fs-uniform-array-loop-unroll.shader_test was designed
> to do an out of bounds access into an uniform array to make sure that we
> handl
Ian Romanick writes:
> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>> The problem in not forcing this to link statically is, that if a
>> distribution decides to not use this static option, the problem persists
>> on that distribution. On top every lib pulled in by steam from the
>> system wo
v2: Use #error in the #else clause, per Jose.
---
include/c99_math.h | 44 ++
src/mesa/main/querymatrix.c | 51 +
2 files changed, 45 insertions(+), 50 deletions(-)
diff --git a/include/c99_math.h b/include/c
On Wed, Mar 11, 2015 at 12:40 PM, Ian Romanick wrote:
> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>> The problem in not forcing this to link statically is, that if a
>> distribution decides to not use this static option, the problem persists
>> on that distribution. On top every lib pulled i
On 11/03/15 16:01, Francisco Jerez wrote:
Vivek Dasmohapatra writes:
Hi -
Hi,
As you probably already know, there can only be one version of
libstdc++.so in your runtime link chain
That's a common misconception, in principle several versions of
libstdc++.so with different DT_SONAME (i.e.
Hi - As you probably already know, there can only be one version of
libstdc++.so in your runtime link chain - This is usually not a problem,
but when things are linked against the Steam runtime (for example), they
can end up with two - one from the steam runtime, and one pulled in via
the mesa dri
Hello all
I'm a college student. I have a project and have to write a graphic driver for
a fixed function GPU that implemented on
a FPGA. my question is : is that possible? and where and how can I start(I ask
for some reference).
I'm apologize for my poor english and if this is the wrong place to
The only hackish ones are llvmpipe and softpipe, which currently return
the same string as for get_vendor(), while ideally they should return
the CPU vendor.
Signed-off-by: Giuseppe Bilotta
---
src/gallium/drivers/freedreno/freedreno_screen.c | 8
src/gallium/drivers/galahad/glhd_scree
This will be needed by Clover to return the correct information
to CL_DEVICE_VENDOR info queries.
Signed-off-by: Giuseppe Bilotta
Reviewed-by: Michel Dänzer
---
src/gallium/docs/source/screen.rst | 6 ++
src/gallium/include/pipe/p_screen.h | 8
2 files changed, 14 insertions(+)
---
src/mesa/drivers/x11/fakeglx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 3869e94..4fd6d75 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -40,6 +40,7 @@
*/
On 03/10/2015 08:47 PM, Ian Romanick wrote:
On 03/10/2015 07:47 PM, Ian Romanick wrote:
On 03/10/2015 06:42 PM, Brian Paul wrote:
We were already using strdup() in various places in Mesa. Get rid
of the _mesa_strdup() wrapper. All the callers pass a non-NULL
argument so the NULL check isn't n
https://bugs.freedesktop.org/show_bug.cgi?id=89553
Bug ID: 89553
Summary: Account request
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=89553
--- Comment #1 from Eduardo Lima Mitev ---
Created attachment 114244
--> https://bugs.freedesktop.org/attachment.cgi?id=114244&action=edit
PGP public key
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
Convert brw->num_atoms to an int array.
Adds brw_add_pipeline_atoms which copies the atoms for a pipeline, and
sets brw->num_atoms[p] for pipeline p.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.h | 8 +++-
src/mesa/drivers/dri/i965/brw_state_upload.c | 72 ++
git://people.freedesktop.org/~jljusten/mesa i965-pipelines
Gen8 appears to require a separate pipeline for CS support.
Here is another take on the multiple pipelines idea. In contrast to
the previous multiple pipeline series, it preserves usage of
brw->state.dirty in most places.
Now, it saves o
Vivek Dasmohapatra writes:
> Hi -
Hi,
> As you probably already know, there can only be one version of
> libstdc++.so in your runtime link chain
That's a common misconception, in principle several versions of
libstdc++.so with different DT_SONAME (i.e. with mutually incompatible
ABIs) can be l
It seems overkill to use LLVM IR for BFE. There are several ways to
express BFE(value, offset, bits) exactly, for example:
# if bits == 0:
# 0
# else if offset + bits < 32:
# (value << (32 - offset - bits)) >> (32 - bits)
# else:
# value >> offset
Which can be simplified to either:
#
https://bugs.freedesktop.org/show_bug.cgi?id=35268
Timo Teräs changed:
What|Removed |Added
CC||timo.te...@iki.fi
--
You are receiving thi
On 03/09/2015 01:44 PM, marius.pre...@intel.com wrote:
From: Marius Predut
Brain Paul review suggestion: there's more macro use here than necessary.
"Brian"
Removed and redefine some #define preprocessing directives.
Removed the directive input parameter 'T' .
No functional changes.
Signed
This patch adds two types of checks to the gl(Compressed)Tex(Sub)Imgage family
of functions when a pixel buffer object is bound to GL_PIXEL_UNPACK_BUFFER:
- That the buffer is not mapped.
- The total data size is within the boundaries of the buffer size.
It does so by calling auxiliary validation
On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
> Hi - As you probably already know, there can only be one version of
> libstdc++.so in your runtime link chain - This is usually not a problem,
> but when things are linked against the Steam runtime (for example), they
> can end up with two - one from
Internal PBO functions such as _mesa_map_validate_pbo_source() and
_mesa_validate_pbo_compressed_teximage() perform validation and buffer mapping
within the same call.
This patch takes out the validation into separate functions to allow reuse
of functionality by other code (i.e, gl(Compressed)Tex(
95 matches
Mail list logo
