On 07/22/2013 02:18 PM, Chris Forbes wrote:
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
docs/GL3.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index f2152a3..64986ea 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -156,5 +156,19 @@
On 07/22/2013 10:42 AM, Paul Berry wrote:
[snip]
I don't mind if someone wants to do some research in the background on
questions 1 and 2 above, but IMHO we can safely proceed with this plan
even without that information. In all likelihood, the only thing we're
going to learn by answering
On 07/22/2013 03:58 PM, Marek Olšák wrote:
There are a couple of reasons why this was missed:
So, I wrote nearly this exact patch in November:
http://lists.freedesktop.org/archives/mesa-dev/2012-November/030209.html
And it was rejected, which explains my skepticism.
1) The depth texture
On 07/14/2013 02:39 AM, Chris Forbes wrote:
This series adds support for GLSL 1.30 / EXT_gpu_shader4's 'flat' and
'noperspective' varying interpolation qualifiers on Gen4/5.
Based on Olivier Galibert's series from July 2012, with some simplifications
(that series contained a number of fixes for
https://bugs.freedesktop.org/show_bug.cgi?id=66806
--- Comment #6 from Vinson Lee v...@freedesktop.org ---
Program received signal SIGFPE, Arithmetic exception.
0x74d4b21f in micro_mul (dst=0x7fffd270, src0=0x7fffd250,
src1=0x7fffd260) at tgsi/tgsi_exec.c:983
983
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
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:
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
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:
The program keys are updated accordingly, but the values are not used
yet.
[V1-2]: Signed-off-by: Olivier Galibert galibert at pobox.com
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
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
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
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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.
---
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
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 something.
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=67127
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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
https://bugs.freedesktop.org/show_bug.cgi?id=67120
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Blocks||67224
--
You are
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 cpuid
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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 jfons...@vmware.com
To: Timothy Arceri t_arc...@yahoo.com.au
Cc: mesa-dev@lists.freedesktop.org; Brian Paul bri...@vmware.com
Sent: Tuesday, 23
On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger srol...@vmware.com 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
From: Roland Scheidegger srol...@vmware.com
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
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 jfons...@vmware.com
To:
- Original Message -
On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger srol...@vmware.com
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
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 -
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
Yes, absolutely, we should have a CAP for that.
Marek
On Wed, Jul 24, 2013 at 12:20 AM, Jose Fonseca jfons...@vmware.com 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
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 in
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 size
On Mon, Jul 15, 2013 at 6:37 AM, Fredrik Höglund fred...@kde.org wrote:
On Monday 15 July 2013, Kenneth Graunke wrote:
Fixes Piglit's ARB_vertex_attrib_bgra/api-errors test.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/varray.c | 10 ++
1 file changed, 10
From: Roland Scheidegger srol...@vmware.com
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
Nice catch! Thanks!
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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
35 matches
Mail list logo
