On Fri, Jun 26, 2015 at 11:40 AM, Marek Olšák wrote:
> If p_atomic_read is fine, then this patch is fine too. So you're
> telling that this should work:
>
> while (p_atomic_read(var));
>
> I wouldn't be concerned about a memory barrier. This is only 1 int, so
> it should make its way into the sha
On Fri, Oct 23, 2015 at 10:55 AM, Eduardo Lima Mitev
wrote:
> When both fadd and fmul instructions have at least one operand that is a
> constant and it is only used once, the total number of instructions can
> be reduced from 3 (1 ffma + 2 load_const) to 2 (1 fmul + 1 fadd); because
> the consta
> >
> > For now, this patch is
> >
> > Reviewed-by: Ian Romanick
>
I had a hard time parsing the title: "Turn -(b2f(a) + b2f(b) >= 0 into
!(a || b)" at first, until I saw the replacement instructions. You're
missing a ')' on the commit line. :)
___
mes
On Sat, Aug 13, 2016 at 10:43 AM, Tobias Klausmann
wrote:
>
>
>
> On 13.08.2016 12:02, Karol Herbst wrote:
>>
>> Signed-off-by: Karol Herbst
>> ---
>> src/gallium/drivers/nouveau/codegen/nv50_ir_target.h| 1 +
>> src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp | 7 ++-
>
>
>
> Yep, no new warnings.
>
> I tried a little test program
> % cat t.cpp
> class asdf {
> int x;
> };
>
> void f() {
> asdf a;
> struct asdf b;
> class asdf c;
> }
>
C++ never ceases to amaze.
> and I can't make it generate warnings (other than unused variables)
> regardless of
On Tue, Jul 15, 2014 at 11:19 AM, Tom Stellard
wrote:
> ---
> src/gallium/auxiliary/util/u_math.h | 22 ++
> src/gallium/drivers/radeonsi/si_shader.c | 8 +---
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_math.h
>
On Fri, Jul 18, 2014 at 2:10 PM, Tom Stellard
wrote:
> v2:
> - Preserve word boundaries.
> ---
> src/gallium/auxiliary/util/u_math.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_math.h
> b/src/gallium/auxiliary/util/u_math.h
> index b
I've been hanging on this list for a while, and this isn't the first time
this has been suggested. The general thing that is repeated is basically
this: if you make an API (e.g. OpenGL) that supports S3TC without a
license, you're in trouble, even if it is a passthrough to the hardware,
which also
Erm... I'm wondering... why does the S3TC issue come up every few
> months out of it's grave and haunt the list (and your nerves) ?
>
>
I think it is because the issue looks deceptively simple. Hardware is
hardware, right? ASICs do the decompression, not software. Surely blindly
copying bits from o
> Any reason for this complicated logic, instead of simply:
>
> while (cs->cdw & 0x7)
> cs->buf[cs->cdw++] = 0x8000;
>
>
Ah, that is eloquently terse; I'm going to have to remember that.
Patrick
> Earthling Michel Dänzer | http://www.amd.co
On Fri, Feb 22, 2013 at 2:23 PM, Ian Romanick wrote:
> On 02/15/2013 11:20 AM, Anuj Phogat wrote:
>
>> tex->Sright and tex->Ttop are initialized during texture allocation.
>> This fixes depth buffer blitting failures in khronos conformance tests
>> when run on desktop GL 3.0.
>>
>> Note: This is
On Mon, Mar 11, 2013 at 9:56 AM, Jose Fonseca wrote:
> I'm surprised this is is faster.
>
> In particular, for big things we'll be touching memory twice.
>
> Did you measure the speed up?
>
> Jose
>
I'm sorry to be dull, but is there a SSE2 implementation of this somewhere
for x86 / x64 CPUs?
P
On Mon, Mar 11, 2013 at 1:30 PM, Jose Fonseca wrote:
> - Original Message -
> > On 03/11/2013 07:56 AM, Jose Fonseca wrote:
> > > I'm surprised this is is faster.
> > >
> > > In particular, for big things we'll be touching memory twice.
> > >
> > > Did you measure the speed up?
> >
> > Th
On Tue, Mar 12, 2013 at 3:39 PM, wrote:
> From: José Fonseca
>
> We were in four already...
> ---
> include/c99_compat.h | 105
> +
> src/egl/main/eglcompiler.h| 44 ++
> src/gallium/include/pipe/p_compiler.h | 74 ++-
Hi all,
Is there a way to see the machine code that is generated by the GLSL
compiler for all GPU instruction sets? For example, I would like to know if
the optimizer optimizes certain (equivalent) constructs (or not), and avoid
them if possible. I know there is a lot to optimization on GPUs that
On Tue, Dec 17, 2013 at 10:59 AM, Paul Berry wrote:
> On 17 December 2013 08:46, Tom Stellard wrote:
>
>> On Tue, Dec 17, 2013 at 09:57:31AM -0600, Patrick Baggett wrote:
>> > Hi all,
>> >
>> > Is there a way to see the machine code that is generate
On Fri, May 2, 2014 at 10:11 AM, wrote:
> From: José Fonseca
>
> Just include stdint.h.
> ---
> src/egl/main/eglcompiler.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/egl/main/eglcompiler.h b/src/egl/main/eglcompiler.h
> index 53dab54..5ea83d6 100644
> --- a/s
On Wed, May 28, 2014 at 2:17 PM, Ian Romanick wrote:
> On 05/27/2014 08:28 PM, Matt Turner wrote:
> > On Tue, May 27, 2014 at 7:49 PM, Ian Romanick
> wrote:
> >> From: Ian Romanick
> >>
> >> No change in the peak ir_variable memory usage in a trimmed apitrace of
> >> dota2 on 64-bit.
> >>
> >>
On Mon, Apr 22, 2013 at 11:14 AM, Eric Anholt wrote:
> This function going to get used a lot more in upcoming patches.
> ---
> src/mesa/swrast/s_texture.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_
I don't think glxgears is the best benchmark for what is a "typical" OpenGL
load (if there is a "typical"). The 60 FPS with your hardware driver sounds
suspiciously like the refresh rate of your screen; perhaps it is
synchronized with the vertical retrace? Since I'm assuming you want to find
the fa
Perhaps 16-bit color isn't supported? Maybe try other color bits or set
R/G/B individually and see what happens. Also, there is an eglinfo tool
source code in Mesa that can probably tell you a whole lot more.
Patrick
On Tue, May 7, 2013 at 7:56 AM, Divick Kishore wrote:
> Hi,
> I have comp
The only difference I could see is that in the old code you passed
&cb->buffer (which maybe points to a value?) directly into u_upload_data()
where as in the new code, you do pass &cb->buffer as the parameter rbuffer
to r600_upload_const_buffer(), but then inside that function, you do
*rbuffer = NU
On Fri, Jun 21, 2013 at 1:29 PM, Eric Anholt wrote:
> Long ago, when porting FBO and memory management support to i965, I
> merged a bunch of code between the i915 and i965 drivers and put it in
> the intel directory. I think it served us well for a long time, as both
> drivers got improvements
On Fri, Jun 21, 2013 at 3:53 PM, Kenneth Graunke wrote:
> On 06/21/2013 01:25 PM, Patrick Baggett wrote:
>
>> I'm not a developer, but I like to keep up with the drivers that I have
>> hardware for. Please take my opinions with a grain of salt.
>>
>> When y
> The latter is true as well. Unfortunately, community work is hampered by
>> the fact that Intel hasn't released public documentation for i915 class
>> hardware. From time to time we've tried to find and motivate the right
>> people to make that happen, but it hasn't yet. Most people in the
>>
On Wed, Jun 26, 2013 at 2:11 AM, Jonathan Gray wrote:
> program_invocation_short_name is glibc specific. Provide an
> alternative using getprogname(), which can be found on *BSD and OS X.
>
> Signed-off-by: Jonathan Gray
> ---
> src/gallium/drivers/r300/r300_chipset.c | 10 +-
> 1 file
My understanding is that this is like having MAP_UNSYNCHRONIZED on at all
times, even when it isn't "mapped", because it is always mapped (into
memory). Is that correct Jose?
Patrick
On Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy wrote:
> On 05.02.2014 18:08, Jose Fonseca wrote:
>
>> I hones
FWIW, memcpy() vs a for() loop has different semantics with respect to
address alignment. I don't know how much it will matter, but last time I
was reading assembly output, copying int[] via for() loop didn't produce a
codepath for 16-byte aligned addresses (allowing for SSE streaming) while
memcpy
On Fri, Dec 12, 2014 at 10:17 AM, Roland Scheidegger
wrote:
> Am 12.12.2014 um 15:09 schrieb Jose Fonseca:
> > From: José Fonseca
> >
> > f0ba7d897d1c22202531acb70f134f2edc30557d made debug_assert()/assert()
> > unsafe for expressions, but only now with u_atomic.h started to rely on
> > them for
Given that there is a _mesa_3dnow_transform_points4_2d in the x86-64 asm
(using MMX/3DNow! is deprecated in x86-64), it appears that this code was
copy-pasted. I wrote a quick patch to change prefetch[w] to prefetcht1,
which is more or less the equivalent in SSE. However, I'm not actually sure
thos
On Mon, Apr 18, 2016 at 9:31 PM, Jonathan Gray wrote:
> Use the defines Mesa configure sets to indicate presence of the bswap32
> builtins. This lets i965 work on OpenBSD again after the changes that
> were made in 0a5d8d9af42fd77fce1492d55f958da97816961a.
>
> Signed-off-by: Jonathan Gray
> ---
On Tue, Nov 4, 2014 at 6:05 AM, Juha-Pekka Heikkila <
juhapekka.heikk...@gmail.com> wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/Makefile.am | 8 +++
> src/mesa/main/x86/sse2_clamping.c | 103
> ++
> src/mesa/main/x86/sse2_clampi
On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy wrote:
> From: Christoph Bumiller
>
> At this moment we use only zero or positive values.
>
> v2: Implement it for also for Solaris, MSVC assembly
> and enable for other combinations.
>
> v3: Replace MSVC assembly by assert + warning during compila
>
>
> Looking at u_atomic.h there is a section that uses
> PIPE_ATOMIC_ASM_MSVC_X86 and has explicit assembly, and there's a
> section that uses PIPE_ATOMIC_MSVC_INTRINSIC and has intrinsics. No
> clue whatsoever what the difference between them is, but presumably it
> doesn't exist solely for the
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga
wrote:
> 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.
>
>
If
>
>
>>
> The restrict keyword is a C99 thing and I don't think it's supported in
> MSVC so that would be a problem. If it won't build with MSVC then it's a
> non-starter. If MSVC can handle "restrict", then I don't know that I care
> much either way about 2 functions or 4
>
>
MSVC uses "__restric
On Wed, Feb 17, 2016 at 3:35 PM, Rob Clark wrote:
> src/compiler/glsl/lower_discard_flow.cpp:79:1: warning: ‘ir_visitor_status
> {anonymous}::lower_discard_flow_visitor::visit_enter(ir_loop_jump*)’ defined
> but not used [-Wunused-function]
> lower_discard_flow_visitor::visit_enter(ir_loop_jump
On Thu, Mar 10, 2016 at 12:25 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Sandy Bridge / Ivy Bridge / Haswell
> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
> instructions in affected programs: 564 -> 558 (-1.06%)
> helped: 6
> HURT: 0
>
> total cycles in shared program
On Thu, Mar 10, 2016 at 3:08 PM, Patrick Baggett
wrote:
> On Thu, Mar 10, 2016 at 12:25 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Sandy Bridge / Ivy Bridge / Haswell
>> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
>> instructi
On Fri, Mar 11, 2016 at 10:21 AM, Ian Romanick wrote:
> On 03/10/2016 01:24 PM, Patrick Baggett wrote:
>> On Thu, Mar 10, 2016 at 3:08 PM, Patrick Baggett
>> wrote:
>>> On Thu, Mar 10, 2016 at 12:25 PM, Ian Romanick wrote:
>>>> From: Ian Romanick
>>&
> What are the rules in C when you compare a double
> variable with a single constant?
>
> void foo(double d)
> {
> /* Does d get converted to single, or does 0.0f get converted to
> * double?
> */
> if (d == 0.0f)
> printf("zero\n");
> }
The 0.0f is converted to a double
On Mon, Mar 28, 2016 at 1:58 PM, Patrick Baggett
wrote:
>> What are the rules in C when you compare a double
>> variable with a single constant?
>>
>> void foo(double d)
>> {
>> /* Does d get converted to single, or does 0.0f get converted to
>>
>
>
> No. Shader compilation can only be asynchronous if it's far enough
> from a draw call and the app doesn't query its status. If it's next to
> a draw call, multithreading is useless. Completely useless.
>
I don't know a lot about the shader compilation/linking process, so
I'm just asking this
> I will point out a couple notes/observations:
>
> Kernel (drm/dri-devel), xorg, and other related projects use the same
> process, and a lot of us do (or at least at some point have) been
> active in 2 or more of these.
>
> Also, I have seen/used some other processes (gerrit, github pulls,
> etc)
Sorry, didn't CC mesa-dev, trying again...
On Wed, Jun 8, 2016 at 4:11 PM, Kenneth Graunke wrote:
> Two dEQP tests expect INVALID_VALUE errors for negative width/height
> parameters, but get INVALID_OPERATION because they haven't actually
> created a destination image. This is arguably not a bug
Would this be conformant to GLSL spec if X had a runtime value of 0? Seems
unsafe to replace X / X with 1 without a runtime test...maybe GLSL spec
allows such optimizations.
On Thu, Aug 7, 2014 at 3:51 PM, wrote:
> From: Thomas Helland
>
> Shows no changes for shader-db.
>
> Signed-off-by: Tho
On Thu, Jan 17, 2013 at 10:37 AM, Brian Paul wrote:
>
> In compiler.h we define the likely(), unlikely() macros which wrap GCC's
> __builtin_expect(). But we only use them in a handful of places.
>
> It seems to me that an obvious place to possibly use these would be for GL
> error testing. For
On Tue, Nov 22, 2011 at 2:07 PM, Marek Olšák wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
> ---
> src/mesa/main/format_unpack.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_un
On Mon, Nov 28, 2011 at 3:32 PM, Daniel Vetter wrote:
> And warn loudly in case people want to use it. Too many tester report
> gpu hangs on irc and we rootcause this ...
>
> Signed-Off-by: Daniel Vetter
> ---
> configure.ac |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
Well, trivial answer is that Win32 uses some C/C++ runtime provided by
Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris uses
libC.so, for example. As far as I know, only systems where the GNU C/C++
compiler is main system compiler (and generally therefore the GNU C++
runtime) uses
On Mon, Jul 30, 2012 at 4:31 AM, Pekka Paalanen wrote:
> On Tue, 24 Jul 2012 11:31:59 -0600
> Brian Paul wrote:
>
> > When computing a matrix inverse, if the determinant is too small we
> could hit
> > a divide by zero. There's a check to prevent this (we basically give up
> on
> > computing th
spers that those cards might function on Power architecture systems, and
I can't help but finding myself impressed. Good job to you all and keep up
the good work.
Patrick Baggett
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.
All,
Is the ATI Rage128 DRI (r128) driver still supported? Does anyone happen to
know of the status?
Patrick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I would be wary of assuming you can typecast long -> pointer, or pointer ->
long. On 64-bit Windows, sizeof(int) == sizeof(long) == 4 but sizeof(void*)
== 8. On 64-bit Linux (gcc), sizeof(int) == 4, sizeof(long) == sizeof(void*)
== 8. It would be better to use with uintptr_t -- it was designed
to
Wasn't nouveau targeted to provide HW acceleration for old cards like the
TNT2, or has that idea been killed?
Patrick
On Sun, Jun 5, 2011 at 2:06 PM, Marcin Slusarz wrote:
> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote:
> > Bail out early in probe, so other driver can take cont
If libOSMesa.so is separate library, then isn't libGL.so too? You're calling
glGetIntegerv() from libGL.so but not from libOSMesa.so -- try doing
dlsym("glGetIntegerv") and removing libGL.so from the link line.
Patrick
On Fri, Jul 15, 2011 at 2:41 PM, Paul Gotzel wrote:
> Hello,
>
> I've downlo
SGI invented OpenGL and offered it first on their IRIX platform. SGI's
MIPSpro compiler has the "char" datatype as unsigned by default, so the
compiler would likely complain if assigning a GLbyte pointer to an
[unsigned] character pointer. Thus, to do something like
char* ext = glGetString(GL_VEND
Might want to fix the copyright message at the top of source file. ;)
On Tue, Aug 2, 2011 at 8:37 AM, Micael Dias wrote:
> ---
> src/mesa/main/mtypes.h |7 +
> src/mesa/state_tracker/st_cb_feedback.c | 21 +-
> src/mesa/state_tracker/st_draw.h | 17
Why not ask the original author to relicense?
2011/8/12 Marek Olšák
> 2011/8/12 Christian König :
> > Am Freitag, den 12.08.2011, 10:49 -0400 schrieb Younes Manton:
> >> Sorry, by incompatible I didn't mean that you couldn't use them
> >> together, but that one is more restrictive than the other
My Voodoo3 3500 AGP just wept.
On Wed, Aug 24, 2011 at 4:36 PM, Eric Anholt wrote:
> On Wed, 24 Aug 2011 12:11:32 -0700, Ian Romanick
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > I'd like to propose giving the ax to a bunch of old, unmaintained
> > drivers. I've been
Now I'm curious. Is it the case that every DRI1 driver *could be* a DRI2
driver with enough effort? Not talking about emulating hardware features.
Patrick
On Thu, Mar 1, 2012 at 1:46 PM, Dave Airlie wrote:
> On Thu, Mar 1, 2012 at 7:25 PM, Connor Behan
> wrote:
> > On 01/03/12 01:36 AM, Dave A
On Fri, May 18, 2012 at 11:28 AM, Brian Paul wrote:
> On 05/18/2012 10:11 AM, Jose Fonseca wrote:
>
>>
>>
>> - Original Message -
>>
>>>
>>> A while back I noticed that the piglit roundmode-pixelstore and
>>> roundmode-getinteger tests pass on my 64-bit Fedora system but fail
>>> on
>>> a
Concurrency::precise_math::signbit(), and only as of VS 2012 runtimes. This
is an awfully high bar for such a simple function.
On Mon, Sep 24, 2012 at 1:43 PM, Matt Turner wrote:
> On Mon, Sep 24, 2012 at 11:02 AM, Brian Paul wrote:
> > On 09/24/2012 10:49 AM, Matt Turner wrote:
> >>
> >> Mod
Is your screen refresh rate 70 Hz? Because if so, that means that it's
syncing to the vblank on Mesa, and not doing so on the proprietary one.
Patrick
On Mon, Oct 29, 2012 at 8:24 PM, Tzvetan Mikov wrote:
> On 10/28/2012 12:56 PM, Tzvetan Mikov wrote:
>
>> On 10/28/2012 04:26 AM, Marek Olšák wr
Hi all,
I've got a really weird duck of system: an Itanium2 system running Linux
3.7.0-rc3 with the newest libdrm and mesa git from yesterday. I configured
it with --enable-texture-float and the radeon DRI driver. When I use
glxinfo, I see that it is Mesa 9.1-devel but only OpenGL 3.0. Is that
bec
DOH. I'm sorry, I read that Mesa supported GL 3.1 and somehow I generalized
that to all drivers. Thanks for that TODO list. I guess I need to start
reading about the R700 architecture...
Patrick
On Wed, Oct 31, 2012 at 1:28 PM, Alex Deucher wrote:
> On Wed, Oct 31, 2012 at 1:11 PM,
On 9/21/2010 9:37 PM, James McKenzie wrote:
I just read a comment that you made in the Mesa mailing list and am
seriously concerned about it:
It only attempts to prevent reverse engineering, disassembly and
decompilation, and does not grant
you distribution rights under copyright law in the
UP = Uniprocessor system, (S)MP = (Symmetric) multiprocessor system.
On Wed, Dec 15, 2010 at 2:23 AM, Marek Olšák wrote:
> On Tue, Dec 14, 2010 at 8:10 PM, Thomas Hellstrom
> wrote:
>
>> Hmm,
>>
>> for the uninformed, where do we need to use spinlocks in gallium and how
>> do
>> we avoid using
I feel like there is some kind of underlying lesson that we, OpenGL app
programmers, should be getting out of this...
What about a psuedo-database of app -> extension list rather than by year?
Surely Quake3 doesn't make use of but <= 10 extensions. I'd imagine the same
holds true for other old gam
Offhand, anyone know when these patents expire?
Patrick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
70 matches
Mail list logo
