On Thu, 2011-03-24 at 16:07 +1100, Christopher James Halse Rogers wrote:
> On Wed, 2011-03-23 at 17:48 -0700, Eric Anholt wrote:
> > On Thu, 24 Mar 2011 10:33:36 +1100, christopher.halse.rog...@canonical.com
> > wrote:
> > > From: Christopher James Halse Rogers
> > >
> > >
> > > The initial-exe
https://bugs.freedesktop.org/show_bug.cgi?id=35268
Christopher James Halse Rogers changed:
What|Removed |Added
Attachment #44412|0 |1
is obsolete|
On Wed, 2011-03-23 at 17:48 -0700, Eric Anholt wrote:
> On Thu, 24 Mar 2011 10:33:36 +1100, christopher.halse.rog...@canonical.com
> wrote:
> > From: Christopher James Halse Rogers
> >
> >
> > The initial-exec static TLS model is inappropriate for libraries
> > that might be dynamically loaded.
On Thu, 24 Mar 2011 10:33:36 +1100, christopher.halse.rog...@canonical.com
wrote:
> From: Christopher James Halse Rogers
>
> The initial-exec static TLS model is inappropriate for libraries
> that might be dynamically loaded. Since libGL is dynamically loaded
> by any number of projects mesa mu
From: Christopher James Halse Rogers
Because the address of a thread-local variable is no longer
a known fixed offset from the TCB it is not possible to run-time
patch the dispatch table to load _glapi_tls_Dispatch with an
immediate instruction.
---
src/mapi/glapi/gen/gl_x86_asm.py | 19 +
From: Christopher James Halse Rogers
---
src/mapi/glapi/gen/gl_x86-64_asm.py | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_x86-64_asm.py
b/src/mapi/glapi/gen/gl_x86-64_asm.py
index 11cd9af..cfe4238 100644
--- a/src/mapi/glapi/gen/gl_x86-
From: Christopher James Halse Rogers
The initial-exec static TLS model is inappropriate for libraries
that might be dynamically loaded. Since libGL is dynamically loaded
by any number of projects mesa must instead use the general-dynamic
TLS model.
This has apparently always been broken for pro
On Wed, Mar 23, 2011 at 10:02 PM, Henri Verbeet wrote:
> Specifically, this ensures things like the front buffer actually exist.
> This
> fixes piglt fbo/fbo-sys-blit and fd.o bug 35483. One concern is that
> st_validate_state() looks expensive, are there any cheaper options?
>
Maybe we should o
https://bugs.freedesktop.org/show_bug.cgi?id=35607
Summary: glXWaitVideoSyncSGI() function freezes at resolution
change
Product: Mesa
Version: git
Platform: All
OS/Version: Linux (All)
Status: NEW
Severity
On 03/23/2011 01:29 PM, Jon TURNEY wrote:
On 15/03/2011 00:23, Brian Paul wrote:
On Mon, Mar 14, 2011 at 4:03 PM, Jon TURNEY wrote:
Can I apply for mesa commit access, since no-one seems to be particularly
interested in picking up my patches?
Sure, there's instructions on the website.
I've
https://bugs.freedesktop.org/show_bug.cgi?id=35601
Brian Paul changed:
What|Removed |Added
Product|Mesa|freedesktop.org
Version|git
Specifically, this ensures things like the front buffer actually exist. This
fixes piglt fbo/fbo-sys-blit and fd.o bug 35483. One concern is that
st_validate_state() looks expensive, are there any cheaper options?
---
src/mesa/state_tracker/st_cb_blit.c |3 +++
1 files changed, 3 insertions(+)
On 23 March 2011 20:23, Henri Verbeet wrote:
> meaningful. However, I could imagine that clearing an obviously
> contiguous block of memory might be somewhat friendlier on the cache
> than interleaving it with various other memory accesses. That's
Actually, ignore that, it's accessed slightly afte
On 15/03/2011 00:23, Brian Paul wrote:
> On Mon, Mar 14, 2011 at 4:03 PM, Jon TURNEY wrote:
>> Can I apply for mesa commit access, since no-one seems to be particularly
>> interested in picking up my patches?
>
> Sure, there's instructions on the website.
I've created a request in bugzilla[1], pl
On 23 March 2011 19:29, Keith Whitwell wrote:
> If you don't do that, I wonder if there is really a gain here -- it
> might be that the original memset was inlined (because it has a known
> size) and the new version just converts that to a non-inlined memset
> with an unknown size?
>
> As it stand
https://bugs.freedesktop.org/show_bug.cgi?id=35601
Summary: Requesting git commit access to mesa
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Comp
On 15/03/2011 00:28, Jakob Bornecrantz wrote:
> On Mon, Mar 14, 2011 at 11:08 PM, Jon TURNEY
> wrote:
>> From: nobled
>>
>> The Hurd kernel doesn't have DRM yet.
>>
>> Signed-off-by: Jon TURNEY
>> Reviewed-by: Julien Cristau
>> ---
>> configure.ac | 13 +++--
>> 1 files changed, 11 i
On 15/03/2011 00:35, Jakob Bornecrantz wrote:
> On Mon, Mar 14, 2011 at 11:08 PM, Jon TURNEY
>> dnl
>> dnl libGL configuration per driver
>> dnl
>> @@ -762,12 +770,17 @@ dri|no) # these checks are still desired when there is
>> no mesa_driver
>> AC_MSG_ERROR([Can't use static libraries
On Mon, 2011-03-21 at 19:55 +0100, Tilman Sauerbeck wrote:
> Keith Whitwell [2011-03-21 18:43]:
> > On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote:
> > > Signed-off-by: Tilman Sauerbeck
> > > ---
> > >
> > > update_samplers() showed up in a profile of Heroes of Newerth;
> > > this patc
On Fri, 18 Mar 2011 16:42:07 -0600, Brian Paul wrote:
> On 03/18/2011 02:31 PM, Jakob Bornecrantz wrote:
> > On Mon, Jan 17, 2011 at 10:40 PM, Eric Anholt wrote:
> >> I'm only interested
> >> in Mesa IR for hardware that doesn't have relative addressing of temps,
> >> so it's not really an issue
Hi everyone,
My name is Emeric, I am a 22 years old french student, and I am
currently looking to apply to the google summer of code 2011.
I saw the "Gallium H.264 decoding" idea on the X.Org GSoC page, and I
am particularly interested by this project.
The idea would be to use shaders to do some w
On Fri, Mar 18, 2011 at 7:17 AM, Srini wrote:
> Hi all,
> I am trying to port mesa for a windowing platform called CDI one like
> XCB,X11. i am successful to all EGL Calls except eglSwapBuffers. so my gles
> application cause segmentation fault when delegating the final rendered
> scene to nativ
22 matches
Mail list logo
