On 10/18/2011 10:50 AM, Peter Hanzel wrote:
> Hello.
>
> I am following Mesa3d-dev mailing list and also found your commit to
> mesa/vmwgfx:
>
> b056516d5efb9386c35f45faf8190e3c211773f8
> vmwgfx: Require HWV8 for 3d support
> On lower versions, the way we mix 2D and 3D may be too slow.
>
> Does th
This avoids exposing the ms driver structure to the winsys,
and nicely encapsulates driver customizable stuff.
In the future more things might be customizable by the winsys, like
throttling, 3D readback etc.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xorg/xorg_driver.c
Jakob Bornecrantz wrote:
> Hi Chia-I and Luca
>
> you guys are doing great work with the EGL state tracker. So I thought
> it would be a good time to open up a discussion about the way that the
> API state trackers talk to the EGL, dri and other co state trackers.
>
> I have attached a proposed
Kristian Høgsberg wrote:
> 2009/12/29 Thomas Hellstrom :
>
>> Kristian,
>>
>> I was looking at how Swapbuffers is done with DRI2 when a fake front is
>> present:
>>
>> The back buffer is copied to the real front, and then the real front is
>>
Keith Whitwell wrote:
> Luca,
>
> This is an impressive body of work. I want to give Jose a chance to
> review the EGL/GLX extensions before pushing, but in the meantime I hope
> it's ok if I make a couple of quick suggestions/requests:
>
> Firstly, we're going to be evolving the TGSI instruction
Michel Dänzer wrote:
> On Wed, 2009-12-30 at 20:37 +0100, Thomas Hellstrom wrote:
>
>> This reverts commit 1336989ec60fff7bd590fefd28945a0e5dc536e3.
>>
>> The commit breaks
>> a) Front buffer rendering on X servers < 1.7.
>> b) The possibility to add con
Ben Skeggs wrote:
> On Wed, 2009-12-30 at 18:45 +0100, Thomas Hellstrom wrote:
>
>> Ben,
>>
> Hey Thomas,
>
>
>> Your commit 1336989ec breaks front buffer rendering on Xserver < 1.7.
>>
>> Shouldn't the change that silently added a
This reverts commit 1336989ec60fff7bd590fefd28945a0e5dc536e3.
The commit breaks
a) Front buffer rendering on X servers < 1.7.
b) The possibility to add conditional front buffer requests on older
X servers.
Since the commit uses a new feature of the DRI protocol, the code must
be conditioned on a
Ben,
Your commit 1336989ec breaks front buffer rendering on Xserver < 1.7.
Shouldn't the change that silently added a fake front attachment have
been accompanied by a bump in SERVER_DRI2_MINOR_VERSION to signal a new
capability? Then we could have inserted some conditional code...
The way tfp
Kristian,
I was looking at how Swapbuffers is done with DRI2 when a fake front is
present:
The back buffer is copied to the real front, and then the real front is
copied back to the fake.
This causes some problems in the vmwgfx drivers where reading from the
real front should be avoided if at
Robert Noland wrote:
> On Tue, 2009-12-01 at 10:17 +0100, Thomas Hellstrom wrote:
>
>> Jakob Bornecrantz wrote:
>>
>>> On 1 dec 2009, at 00.24, Robert Noland wrote:
>>>
>>>
>>>> On Tue, 2009-12-01 at 10:37 +1100, Daniel
Thomas Hellstrom wrote:
> Jakob Bornecrantz wrote:
>
>> On 1 dec 2009, at 00.24, Robert Noland wrote:
>>
>>
>>> On Tue, 2009-12-01 at 10:37 +1100, Daniel Stone wrote:
>>>
>>>
>>>>
Jakob Bornecrantz wrote:
> On 1 dec 2009, at 00.24, Robert Noland wrote:
>
>> On Tue, 2009-12-01 at 10:37 +1100, Daniel Stone wrote:
>>
>>> On Mon, Nov 30, 2009 at 11:21:47AM -0600, Robert Noland wrote:
>>>
I've tried to ask linux folk if this is also true for linux, but the
>>>
Brian Paul wrote:
> Brian Paul wrote:
>
>> Thomas Hellstrom wrote:
>>
>>> Brian Paul wrote:
>>>
>>>> Thomas & Jose, I think you are most familiar with this code...
>>>>
>>>> The attached patch fixes a bug I
Brian Paul wrote:
> Thomas & Jose, I think you are most familiar with this code...
>
> The attached patch fixes a bug I found with softpipe and
> glDrawPixels(GL_STENCIL_INDEX).
>
> The failing case was basically:
>
> glClear(GL_STENCIL_BUFFER_BIT);
> ...
> glDrawPixels(GL_STENCIL_INDEX).
>
> Draw
Signed-off-by: Thomas Hellstrom
---
src/mesa/state_tracker/st_cb_texture.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 15f84b6..3f76b07 100644
--- a/src/mesa
T
to indicate whether the internal texture image format is suitable as
a depth / stencil or color render target respective.
Note: For backwards compatibility, these default to GL_TRUE.
Signed-off-by: Thomas Hellstrom
---
src/mesa/main/fbobject.c | 14 ++
src/mesa/main/mtypes.h |
T
to indicate whether the internal texture image format is suitable as
a depth / stencil or color render target respective.
Note: For backwards compatibility, these default to GL_TRUE.
Signed-off-by: Thomas Hellstrom
---
src/mesa/main/fbobject.c | 14 ++
src/mesa/main/mtypes.h |
Signed-off-by: Thomas Hellstrom
---
src/mesa/state_tracker/st_cb_texture.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 15f84b6..3f76b07 100644
--- a/src/mesa
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thomas Hellstrom wrote:
>
>> Hi!
>>
>> Sorry for attching the patch like this, but for some reason it was
>> blocked when I tried to send it the normal way.
>>
>> This p
Thomas Hellstrom wrote:
Hi!
Sorry for attching the patch like this, but for some reason it was
blocked when I tried to send it the normal way.
This patch bumps some dri interface versions, and I'm not sure when /
whether that is allowed.
Please review!
Thanks
T
Hi!
Sorry for attching the patch like this, but for some reason it was
blocked when I tried to send it the normal way.
This patch bumps some dri interface versions, and I'm not sure when /
whether that is allowed.
Please review!
Thanks
Thomas
-
José Fonseca wrote:
> On Sun, 2009-05-03 at 03:05 -0700, Thomas Hellström wrote:
>
>> Jose Fonseca wrote:
>>
>>> gallium-screen-context adds a new callback to create a context with a
>>> screen. This is very useful when one stacks pipe drivers on top of another
>>> (like the trace pipe dr
Younes Manton wrote:
On Fri, Apr 17, 2009 at 2:22 PM, Thomas Hellstrom wrote:
Ideally this flushing would've been done in the various map operations within
the pipe driver as you say, but
unfortunately these map operations are screen operations, so the pipe driver
doesn't
teximage -subimage and you'll probably see the rendering error
without this fix.
Thanks,
/Thomas
From: Younes Manton [youne...@gmail.com]
Sent: Friday, April 17, 2009 17:34
To: Thomas Hellstrom; Mesa3d-dev@lists.sourceforge.net
Subject: gallium: Make
Dave Airlie wrote:
> valgrind was showing a race between the drawable getting destroyed
> by the X resource freeing code, and the context getting destroyed
> later and freeing the drawable.
>
> However I've no idea if some other combination of things could cause
> this code to leak.
>
> Any one els
Younes Manton wrote:
> On Wed, Apr 1, 2009 at 3:52 AM, Thomas Hellstrom
> wrote:
>
>> Ian Romanick wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> thellst...@vmware.com wrote:
>>>
>>>
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> thellst...@vmware.com wrote:
>
>> From: Thomas Hellstrom
>>
>> 1) Don't error-check here. It's done in makeCurrent.
>> 2) Don't segfault if ctx happens to be 0.
>
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> thellst...@vmware.com wrote:
>
>> From: Thomas Hellstrom
>>
>> 1) If MakeContextCurrent is called with (NULL, None, None), Don't
>>send the request to the X server if
Kristian Høgsberg wrote:
> On Mon, Mar 30, 2009 at 4:46 AM, Thomas Hellstrom
> wrote:
>
>> Hi!
>>
>> Thomas Hellstrom wrote:
>>
>>> Hi!
>>>
>>> I've sent two glx dri patches for review. The first one does some minor
>>
Hi!
Thomas Hellstrom wrote:
> Hi!
>
> I've sent two glx dri patches for review. The first one does some minor
> optimizations and propagates driver makeCurrent back.
> The second one is intended to fix the makeContextCurrent(NULL, None,
> None) call and to do some ad
Hi!
I've sent two glx dri patches for review. The first one does some minor
optimizations and propagates driver makeCurrent back.
The second one is intended to fix the makeContextCurrent(NULL, None,
None) call and to do some additional error checking. This was prompted
by the newly added shared
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dave Airlie wrote:
>
>> Hey,
>>
>> So I've been playing with radeon FBOs and have run into a problem with how
>> to allow apps to get an FBOs that isn't swrast fallback :-)
>>
>> radeons can by default render to ARGB,
Hi
Kristian Høgsberg wrote:
> 2009/3/24 Thomas Hellstrom :
>
>> Hi!
>>
>> It looks like the dri implementation is quite broken for
>> makeContextCurrent(NULL, None, None).
>> Drivers expect this to get through to the driver makeCurrent hook to be able
Hi!
It looks like the dri implementation is quite broken for
makeContextCurrent(NULL, None, None).
Drivers expect this to get through to the driver makeCurrent hook to be
able to flush and to notify core mesa.
However the current glx code sends this request to the X server only,
and the dri bin
Hi, Dave,
Dave Airlie wrote:
> Hey,
>
> So I've been playing with radeon FBOs and have run into a problem with how
> to allow apps to get an FBOs that isn't swrast fallback :-)
>
> radeons can by default render to ARGB, ARGB, RGB565 mostly, now in
> this case when the app asks for a text
Michel Dänzer wrote:
> On Die, 2009-03-17 at 16:38 +0100, Thomas Hellstrom wrote:
>
>> Michel Dänzer wrote:
>>
>>> On Die, 2009-03-17 at 14:12 +0100, Thomas Hellstrom wrote:
>>>
>>>
>>>>>
>>>>>
Michel Dänzer wrote:
> On Die, 2009-03-17 at 14:12 +0100, Thomas Hellstrom wrote:
>
>>>
>>>
>> Attached is a program that should be linked with -lpthread -lX11.
>> For me it deadlocks immediately with an XCB-enabled Xlib, but works fine
>>
Thomas Hellstrom wrote:
Keith Whitwell wrote:
On Tue, 2009-03-17 at 03:56 -0700, José Fonseca wrote:
On Tue, 2009-03-17 at 03:39 -0700, Thomas Hellstrom wrote:
Thomas Hellström wrote:
Hi!
I'm currently looking into the thread-safety of the dri dr
Keith Whitwell wrote:
> On Tue, 2009-03-17 at 03:56 -0700, José Fonseca wrote:
>
>> On Tue, 2009-03-17 at 03:39 -0700, Thomas Hellstrom wrote:
>>
>>> Thomas Hellström wrote:
>>>
>>>> Hi!
>>>>
>>>> I'm cur
Thomas Hellström wrote:
> Hi!
>
> I'm currently looking into the thread-safety of the dri drivers. In
> particular the calls to libX11.
>
> It appears that many of the applications I've tried have issues with
> deadlocks in the XCB code.
> It looks like this might be an issue with the locking ord
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thomas Hellström wrote:
>
>> Ian Romanick wrote:
>> MichaŠKról wrote:
>>
>>
> Module: Mesa
> Branch: master
> Commit: a7d42e11b4e97f19eaeb3b5ee811f04adb05b13d
> URL:
> http://cgit.freedesk
José Fonseca wrote:
> On Mon, 2009-03-16 at 06:09 -0700, Michał Król wrote:
>
>> On Mon, Mar 16, 2009 at 1:59 PM, José Fonseca wrote:
>>
>>> Shouldn't we use InterlockedIncrement
>>> ( http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx ) and
>>> friends in Windows instead of asse
Michał Król wrote:
> On Mon, Mar 16, 2009 at 10:41 AM, Thomas Hellstrom
> wrote:
>
>> tom fogal wrote:
>>
>>> thellst...@vmware.com writes:
>>> [snip]
>>>
>>>
>>>> +#if (defined(PIPE_CC_GCC) && defined
tom fogal wrote:
> thellst...@vmware.com writes:
> [snip]
>
>> +#if (defined(PIPE_CC_GCC) && defined(__i386__))
>>
>
> ^
>
> This is basically an #ifdef (__GNUC__), I'm guessing?
>
>
Yes, however it seems like the rest of the gallium code is using private
define
Brian Paul wrote:
> Thomas Hellstrom wrote:
>
>> When comparing the visual appearance of the "fire" application between
>> mesa 7.0 and current HEAD it seems to be quite different. Objects (part
>> of trees) are present close to the viewer in current HEAD
When comparing the visual appearance of the "fire" application between
mesa 7.0 and current HEAD it seems to be quite different. Objects (part
of trees) are present close to the viewer in current HEAD but not with
mesa 7.0, and the app itself hasn't changed. Does anybody have any insights?
/Tho
I've pushed the new openchrome driver to the openchrome-branch.
It should probably remain there until the new user-space ttm headers hit a
libdrm or a kernel release.
.
It runs with the
ttm-branch of the openchrome 2D-driver svn
modesetting-newttm drm and
libwsbm master (git://git.freedesktop.
OK.
Comment added.
Thanks,
Thomas
From: Keith Whitwell [kei...@vmware.com]
Sent: Tuesday, January 20, 2009 11:16
To: Thomas Hellstrom
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] [PATCH] tnl: Add a utility function to emit indexed
49 matches
Mail list logo
