-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
> The plan is to implement a rgba signed 8-bit format (to keep the
> extension simple) and reuse the Nvidia enums (certainly the full set of
> rgb/rgba/luminance/etc. could be exposed, but there are no plans for
> that, it co
On 16.03.2009 20:44, Ian Romanick wrote:
> Keith Whitwell wrote:
>>> The only hardware that can support this extension that doesn't already
>>> have support for ARB_fragment_shader is G400 and R100. Convince me that
>>> we really want to clutter Mesa with shit extensions to add functionality
>>> t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> I'm posting to mesa3d-dev because there doesn't appear to be a piglit
> mailing list.
>
> I have a couple tests that I'd like to add to piglit, but I've written
> them to use GLEW. Is that okay? I prefer GLEW over just defining
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm posting to mesa3d-dev because there doesn't appear to be a piglit
mailing list.
I have a couple tests that I'd like to add to piglit, but I've written
them to use GLEW. Is that okay? I prefer GLEW over just defining
GL_GLEXT_PROTOTYPES or trying
-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.freedesktop.org/mesa/mesa/commit/?id=a7d42e11b4e97f19eae
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 order of
XLockDisplay() and driver mutex
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> MichaŠKról wrote:
>
>> Module: Mesa
>> Branch: master
>> Commit: a7d42e11b4e97f19eaeb3b5ee811f04adb05b13d
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a7d42e11b4e97f19eaeb3b5ee811f04adb05b13d
>>
>> Aut
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
MichaŠKról wrote:
> Module: Mesa
> Branch: master
> Commit: a7d42e11b4e97f19eaeb3b5ee811f04adb05b13d
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a7d42e11b4e97f19eaeb3b5ee811f04adb05b13d
>
> Author: Michal Krol
> Date: Mon Mar 16
--- On Mon, 16/3/09, Ian Romanick wrote:
> I'd bet a shiny nickel that WoW only uses when
> ARB_fragment_program and ARB_fragment_shader are not available. :)
Possible, although:
a) $ strings /opt/wine/World\ of\ Warcraft/WoW.exe | grep ARB_fragment
GL_ARB_fragment_program
(No ARB_fragment_sha
On Mon, 2009-03-16 at 12:44 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Keith Whitwell wrote:
> >
> >> The only hardware that can support this extension that doesn't already
> >> have support for ARB_fragment_shader is G400 and R100. Convince me that
> >> we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Ian Romanick wrote:
>> What spurred this is that we (Intel) are doing our quarterly driver
>> release at the end of the month. Our preferred method is to take the
>> current Mesa stable branch or stable release to use as the basis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
>
>> The only hardware that can support this extension that doesn't already
>> have support for ARB_fragment_shader is G400 and R100. Convince me that
>> we really want to clutter Mesa with shit extensions to add functionality
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Rankin wrote:
> --- On Mon, 16/3/09, Roland Scheidegger wrote:
>> I think though outside of trying to run d3d apps in one way or another
>> there's very few apps out there which would use this extension (I don't
>> know of any but maybe they exi
José Fonseca pisze:
> 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
--- On Mon, 16/3/09, Roland Scheidegger wrote:
> I think though outside of trying to run d3d apps in one way or another
> there's very few apps out there which would use this extension (I don't
> know of any but maybe they exist - I wasn't able to find some sample code
> using this outside of ati
On 16.03.2009 16:37, Chris Rankin wrote:
> --- On Mon, 16/3/09, Roland Scheidegger wrote:
>> you forgot to mention the R200 - not that it makes much difference,
>> and I wouldn't know exactly how to implement this on these chips,
>> though it probably wouldn't be too difficult.
>
> What about R30
--- On Mon, 16/3/09, Roland Scheidegger wrote:
> you forgot to mention the R200 - not that it makes much
> difference, and I wouldn't know exactly how to implement this on these
> chips, though it probably wouldn't be too difficult.
What about R300+ too? Yes, this hardware might theoretically of
On 16.03.2009 14:03, Keith Whitwell wrote:
>
>> The only hardware that can support this extension that doesn't already
>> have support for ARB_fragment_shader is G400 and R100. Convince me that
>> we really want to clutter Mesa with shit extensions to add functionality
>> to support 10 year old h
http://bugs.freedesktop.org/show_bug.cgi?id=19296
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 assembly? It is implemented as a compile
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 assembly? It is implemented as a compiler
> intrinsic, so it probably results in more efficient genera
> The only hardware that can support this extension that doesn't already
> have support for ARB_fragment_shader is G400 and R100. Convince me that
> we really want to clutter Mesa with shit extensions to add functionality
> to support 10 year old hardware.
Roland can probably give a much better
Shouldn't we use InterlockedIncrement
( http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx ) and
friends in Windows instead of assembly? It is implemented as a compiler
intrinsic, so it probably results in more efficient generated code.
Jose
On Mon, 2009-03-16 at 05:42 -0700, Micha?? Kr
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(__i386__))
>>> ^
>>>
>>> This is basi
On Mon, Mar 16, 2009 at 6:26 AM, Keith Whitwell wrote:
> On Sat, 2009-03-14 at 17:21 -0700, Younes Manton wrote:
> Ugh, sorry about this. I'm not sure how I didn't pick these up - I must
> have had these drivers disabled in my build without realizing it. Sorry
> for the screwup.
>
> Keith
No bi
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(__i386__))
>>>
>>
>> ^
>>
>> This is basically an #ifdef (__GNUC__), I'm guessing?
>>
>>
> Yes, however it s
On Sat, 2009-03-14 at 17:21 -0700, Younes Manton wrote:
> Module: Mesa
> Branch: master
> Commit: 8b45de9aa1f92630b3c92847e20fc68d7b202edd
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=8b45de9aa1f92630b3c92847e20fc68d7b202edd
>
> Author: Younes Manton
> Date: Sat Mar 14 20:19:47
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
On Mon, Mar 16, 2009 at 05:43, Daniel Connery wrote:
> So I have been scouring the archives for two days now and havent
> found anything related to this. So I am just going to post this
> question and hope I dont get flamed. If a discussion about this exists
> could you please just point me
29 matches
Mail list logo
