On Tue, Jul 23, 2013 at 2:52 PM, wrote:
> From: Roland Scheidegger
>
> CPU detection is not really x86 specific, the ifdef in particular didn't
> even catch x86_64.
> Also move to draw context creation which seems a lot cleaner, and just
> call it always (which seems like a better idea than rely
Nice catch! Thanks!
- Original Message -
> From: Roland Scheidegger
>
> CPU detection is not really x86 specific, the ifdef in particular didn't
> even catch x86_64.
> Also move to draw context creation which seems a lot cleaner, and just
> call it always (which seems like a better idea
From: Roland Scheidegger
Since disabling denorms in draw_vbo() we require the util_cpu_caps to be
initialized there. Hence add another util_cpu_detect() call in
draw_create_context() which should ensure this.
(There is another call in draw_get_option_use_llvm() which only gets called
with x86 (no
On Mon, Jul 15, 2013 at 6:37 AM, Fredrik Höglund wrote:
> On Monday 15 July 2013, Kenneth Graunke wrote:
>> Fixes Piglit's ARB_vertex_attrib_bgra/api-errors test.
>>
>> Signed-off-by: Kenneth Graunke
>> ---
>> src/mesa/main/varray.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff
On Mon, Jul 22, 2013 at 09:24:56AM -0400, Jonathan Charest wrote:
> To have non-static buffers in local memory, it is necessary to pass them
> as arguments to the kernel.
>
> For r600, the correct lds size must be set to the SQ_LDS_ALLOC register.
> The correct size is the clover size plus the siz
On Mon, Jul 22, 2013 at 09:24:12AM -0400, Jonathan Charest wrote:
> To have non-static buffers in local memory, it is necessary to pass them
> as arguments to the kernel. This was almost supported but the address
> space mapping was missing to perform the check (thanks to tstellar for
> pointing me
Yes, absolutely, we should have a CAP for that.
Marek
On Wed, Jul 24, 2013 at 12:20 AM, Jose Fonseca wrote:
> - Original Message -
>> FYI, OpenGL 4.4, which was released yesterday, adds GL_MAP_PERSISTENT
>> and GL_MAP_COHERENT bits as valid parameters of glMapBufferRange and
>> glBufferS
- Original Message -
> FYI, OpenGL 4.4, which was released yesterday, adds GL_MAP_PERSISTENT
> and GL_MAP_COHERENT bits as valid parameters of glMapBufferRange and
> glBufferStorage, allowing to use buffers for rendering while they are
> mapped and upload/download data to/from the buffers s
On 07/23/2013 10:20 AM, Zack Rusin wrote:
this is a wonky requirement of d3d10, which expects that if
indexed rendering call is issued without an indexed buffer
bound, the rendering should still happen but with all indices
set to 0.
The series looks good to me.
Reviewed-by: Brian Paul
- Original Message -
> On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger
> wrote:
> > Am 23.07.2013 19:08, schrieb Andre Heider:
> >> For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
> >> supports these extensions, but the OS doesn't, issuing these insns will
> >
I'll send you a tarball with some patches and source files.
-Brian
On 07/23/2013 03:42 PM, Timothy Arceri wrote:
Hi Brian,
Where can I get a copy of you unfinished work on the GL_KHR_debug extension?
Thanks,
Tim
- Original Message -
From: Jose Fonseca
To: Timothy Arceri
Cc: mesa-
From: Roland Scheidegger
CPU detection is not really x86 specific, the ifdef in particular didn't
even catch x86_64.
Also move to draw context creation which seems a lot cleaner, and just
call it always (which seems like a better idea than rely on drivers doing this
especially if drivers otherwis
On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger wrote:
> Am 23.07.2013 19:08, schrieb Andre Heider:
>> For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
>> supports these extensions, but the OS doesn't, issuing these insns will
>> trigger an undefined opcode exception.
>>
Hi Brian,
Where can I get a copy of you unfinished work on the GL_KHR_debug extension?
Thanks,
Tim
- Original Message -
From: Jose Fonseca
To: Timothy Arceri
Cc: mesa-dev@lists.freedesktop.org; Brian Paul
Sent: Tuesday, 23 July 2013 11:25 PM
Subject: Re: [Mesa-dev] Advice for implem
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 07/23/2013 03:26 AM, Chris Forbes wrote:
If any component used the ZERO or ONE swizzle, its corresponding member
in the `swizzle` array would never be initialized. We *mostly* got away
with this, except when that memory happened to contain a value that
clobbered another channel when combined u
Am 23.07.2013 19:08, schrieb Andre Heider:
> For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
> supports these extensions, but the OS doesn't, issuing these insns will
> trigger an undefined opcode exception.
>
> In addition to the AVX cpuid bit we also need to:
> * test cpu
https://bugs.freedesktop.org/show_bug.cgi?id=67120
Ian Romanick changed:
What|Removed |Added
Blocks||67224
--
You are receiving this mail bec
fwiw, I found a couple more places assuming a PCI device
(dri2_get_driver_for_fd() and drm_fd_get_pci_id()).. I'm kinda
thinking it would make sense to refactor this out a bit into a common
load_me_the_right_driver() type fxns..
BR,
-R
On Fri, Jul 19, 2013 at 3:13 PM, Thierry Reding
wrote:
> Fr
https://bugs.freedesktop.org/show_bug.cgi?id=67127
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=67127
--- Comment #4 from Vinson Lee ---
mesa: 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 (master)
$ ldd -r build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5
linux-vdso.so.1 => (0x7fff9bdff000)
libX11.so.6 => /usr/lib/x86_64-
https://bugs.freedesktop.org/show_bug.cgi?id=66806
--- Comment #9 from Vinson Lee ---
I can reproduce this bug with gcc 4.4.7 on CentOS 6, gcc 4.6.3 on Ubuntu 12.04,
gcc 4.7.3 on Ubuntu 13.04, and gcc 4.8.1 on Ubuntu 13.10.
--
You are receiving this mail because:
You are the assignee for the bu
The linker matches up variables in interface blocks according to their
block name and variable name. When support for interface block arrays
was added in commit d6863acb, we renamed variables appearing in
interface blocks so that their name included the array size. For
example, in a block like th
For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
supports these extensions, but the OS doesn't, issuing these insns will
trigger an undefined opcode exception.
In addition to the AVX cpuid bit we also need to:
* test cpuid for OSXSAVE support
* XGETBV to check if the OS save
https://bugs.freedesktop.org/show_bug.cgi?id=67127
--- Comment #3 from José Fonseca ---
Oh, this is with icc? I never tested.
I suspect that the build with icc has _always_ has been broken. This commit
just brought that problem back to surface (as was the intention).
This is easy to check: what
https://bugs.freedesktop.org/show_bug.cgi?id=66806
--- Comment #8 from Roland Scheidegger ---
Vinson,
this looks like a compiler issue to me, what compiler are you using? I suspect
something funky might be going on when setting/getting mxcsr value. A
disassembly of draw_vbo() where these are set
this is a wonky requirement of d3d10, which expects that if
indexed rendering call is issued without an indexed buffer
bound, the rendering should still happen but with all indices
set to 0.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_private.h |5 +++--
src/gallium/a
vertex id has to be unaffected by the start index (i.e. when calling
draw arrays with start_index = 5, the first vertex_id has to still
be 0, not 5) and it has to be equal to the index when performing
indexed rendering (in which case it has to be unaffected by the
index bias). This fixes our behavi
The instance id system value always starts at 0, even if the
specified start instance is larger than 0. Instead of implicitly
setting instance id to instance id plus start instance and then
having to subtract instance id when computing the buffer offsets
lets just set instance id to the proper inst
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> The codeword must be unsigned (otherwise will shift in 1's from above when
> merging low/high parts so some texels decode wrong).
> This also affects gallium's util/u_format_rgtc.
> ---
> src/mesa/main/texcompr
On Tue, 2013-07-23 at 08:39 +1000, Dave Airlie wrote:
> On Tue, Jul 23, 2013 at 8:21 AM, Marek Olšák wrote:
> > I think this is radically different from d3d1x, as it already can be
> > used to play games from Blizzard, Bethesda, and other companies
> > according to Christoph. I don't think this is
I've done a bit more work and I think I have answered my own question.
mesa_debug_type, mesa_debug_severity can be extended and used by both
extensions as long as the correct validation is done in the functions.
Then I can create a second struct gl_khr_debug_state (which is a KHR_debug
version
https://bugs.freedesktop.org/show_bug.cgi?id=66806
--- Comment #7 from Roland Scheidegger ---
(In reply to comment #6)
> (gdb) info registers mxcsr
> mxcsr 0x8060 [ PE DAZ FZ ]
Hmm that is just crazy, somehow all exceptions got unmasked and we get a
precision exception (which is really u
Brian Paul has an early draft [1]. You should start from there.
Jose
[1] http://lists.freedesktop.org/archives/mesa-dev/2013-June/040171.html
- Original Message -
> Hi All,
>
> I've been stalking this list for a while now and I thought I'd finally make
> an attempt to contribute somethi
Hello David,
On 18/07/13 08:48, Dave Airlie wrote:
since I suppose these communities would be most interested in this and
might not all read my blog or G+ stream,
"Virgil is a research project I've been working on at Red Hat for a
few months now and I think is ready for at least announcing upst
- Original Message -
> From: Roland Scheidegger
>
> The codeword must be unsigned (otherwise will shift in 1's from above when
> merging low/high parts so some texels decode wrong).
> This also affects gallium's util/u_format_rgtc.
> ---
> src/mesa/main/texcompress_rgtc_tmp.h | 6 ++
FYI, OpenGL 4.4, which was released yesterday, adds GL_MAP_PERSISTENT
and GL_MAP_COHERENT bits as valid parameters of glMapBufferRange and
glBufferStorage, allowing to use buffers for rendering while they are
mapped and upload/download data to/from the buffers simultaneously.
It's now clear that Ga
If any component used the ZERO or ONE swizzle, its corresponding member
in the `swizzle` array would never be initialized. We *mostly* got away
with this, except when that memory happened to contain a value that
clobbered another channel when combined using BRW_SWIZZLE4().
NOTE: This is a candidat
The program keys are updated accordingly, but the values are not used
yet.
[V1-2]: Signed-off-by: Olivier Galibert
V3: Updated for vue_map changes, intel -> brw merge, etc. (Chris Forbes)
V4: Compute interpolation map as a new state atom rather than tacking it
on the front of the clip setup
Sig
On 07/22/2013 03:58 PM, Marek Olšák wrote:
There are a couple of reasons why this was missed:
1) The depth texture mode doesn't exist in the core profile, so the
core spec doesn't and cannot specify what the default should be, so
that's why nobody updated it. However the 4.1 core spec says:
"3.
Hi All,
I've been stalking this list for a while now and I thought I'd finally make an
attempt to contribute something. I've decided the KHR_debug extension is a good
place to start as the ARB_debug_output provideds a great starting point.
However I've hit my first road block.
I'm ready to se
On 07/14/2013 02:39 AM, Chris Forbes wrote:
Previously we only gave special treatment to the builtin color varyings.
This patch adds support for arbitrary flat-shaded varyings, which is
required for GLSL 1.30.
Based on Olivier Galibert's patch from last year:
http://lists.freedesktop.org/archive
On 07/14/2013 02:39 AM, Chris Forbes wrote:
Previously the SF only handled the builtin color varying specially.
This patch generalizes that support to cover user-defined varyings,
driven by the interpolation mode array set up alongside the VUE map.
Based on the following patches from Olivier Gal
43 matches
Mail list logo
