>> - num_surfaces = (gctx->base.ReadSurface == gctx->base.DrawSurface) ? 1 :
>> 2;
>> - for (s = 0; s < num_surfaces; s++) {
>> + for (s = 0; s < 2; s++) {
> Why this change?
Ignore it.
>> struct pipe_texture *textures[NUM_NATIVE_ATTACHMENTS];
>> struct egl_g3d_surface *gsurf;
>
On Mon, Jan 4, 2010 at 11:12 PM, Luca Barbieri wrote:
> The current code revalidates based on whether width or height have changed.
> This is unreliable (it may change two times, with another context having got
> the buffers for the intermediate size in the meantime) and causes two DRI2
> calls.
> This looks good. Do you mind re-create this patch without the
> dependency on the depth/stencil patch?
OK.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class a
> I left out depth/stencil attachment because I could not think of a good reason
> for it. Do you have an example that it is better to ask the display server
> for
> a depth/stencil buffer than asking the pipe driver?
I'm not sure about this. I mostly added it just because the old driver
stack a
On Mon, Jan 4, 2010 at 11:12 PM, Luca Barbieri wrote:
> Currently DRI2 always calls texture_from_shared_handle on validate.
> This may cause problems due if it is called multiple times on the same
> handle, since multiple struct pipe_texture pointing to the same GEM buffer
> will be created.
> O
On Mon, Jan 4, 2010 at 11:12 PM, Luca Barbieri wrote:
> It is implemented by adding a new depth/stencil native attachment.
> While depth seems to work even without this, due to the Mesa state tracker
> creating it itself, this is the way other DRI2 drivers work and might work
> better in some ca
On Tue, Jan 12, 2010 at 12:39 PM, Luca Barbieri wrote:
> Indeed both EGL 1.0 and EGL1.4 contain that language in the specs, but
> the Khronos manpage does not.
> I think we can safely ignore this.
> Applications are very unlikely to rely on eglSwapBuffers failing in
> that case, and anyway the spe
The hybrid approach is appealing to me, since Radeons are so damn
quirky, but anything not requiring me to set up the dedicated fog
block wins my vote.
~ C.
On Mon, Jan 11, 2010 at 1:50 PM, Jakob Bornecrantz wrote:
>
> On 11 jan 2010, at 21.17, Zack Rusin wrote:
>
>> On Monday 11 January 2010 16
Indeed both EGL 1.0 and EGL1.4 contain that language in the specs, but
the Khronos manpage does not.
I think we can safely ignore this.
Applications are very unlikely to rely on eglSwapBuffers failing in
that case, and anyway the specification explicitly prohibits them from
doing so by saying that
On Tue, Jan 12, 2010 at 12:23 PM, Luca Barbieri wrote:
>> Regardless of my personal preference as expressed, there are some minor
>> issues
>> in the EGL part of the patch. One is that, it lifts certain restrictions
>> required by EGL 1.4 by commenting out the code (e.g. in eglSwapBuffers). It
Hi all,
I just pushed a new EGL driver (egl_g3d) to master. The new driver is located
at src/gallium/state_trackers/egl_g3d/. When built, it provides .a archives
that are later linked to by src/gallium/winsys/drm//egl_g3d/ to provide the
final EGL drivers loadable by libEGL.
This new driver sup
> Regardless of my personal preference as expressed, there are some minor issues
> in the EGL part of the patch. One is that, it lifts certain restrictions
> required by EGL 1.4 by commenting out the code (e.g. in eglSwapBuffers). It
> should check if EGL_MESA_gallium is supported and decide what
On Sun, Jan 3, 2010 at 3:33 PM, Chia-I Wu wrote:
> This patch series brings a new EGL (meta) driver, libegl.a. Like
> libegldrm.a living under state_trackers/egl/, the build process uses it
> to build various EGL drivers, like egl_i915.so, egl_radeon.so, and etc.
> I've only tested egl_i915. myse
On Tue, Jan 12, 2010 at 5:06 AM, José Fonseca wrote:
> I think that there was enough time for everybody interested to voice
> their opinion.
> I'm going to start committing Luca's patches.
Are both GLX_MESA_gallium and EGL_MESA_gallium required for direct Gallium
access? If GLX_MESA_gallium alone
On Mon, Jan 11, 2010 at 11:33 AM, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 11:18 -0800, Luca Barbieri wrote:
>> > gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
>> > -I../../src/gallium/auxiliary -Wall -Wmissing-prototypes
>> > -Wdeclaration-after-statement -Wpointer-ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
> I thought MSVC supported C99, but that seems not to be the case.
>
> However, it seems to have partial C99 support, and according to MSDN
> the particular case of for loop initializers C99 behaviour may be
> selected with /Zc:fo
Hi all,
Am 10.12.2009 17:36, schrieb José Fonseca:
> On Thu, 2009-12-10 at 08:31 -0800, Jose Fonseca wrote:
>
>> Module: Mesa
>> Branch: glsl-pp-rework-2
>> Commit: 491f384c3958067e6c4c994041f5d8d413b806bc
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=491f384c3958067e6c4c9940
On Monday 11 January 2010 18:18:30 Michel Dänzer wrote:
> On Mon, 2010-01-11 at 18:05 -0500, Zack Rusin wrote:
> > On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
> > > A better fix should be to make sure the exaMoveInPixmap() call is
> > > before the exaGetPixmapDriverPrivate() call. The l
On Mon, 2010-01-11 at 18:05 -0500, Zack Rusin wrote:
> On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
> > A better fix should be to make sure the exaMoveInPixmap() call is before
> > the exaGetPixmapDriverPrivate() call. The latter should never return
> > NULL then (unless we run out of r
It's better to revert that commit for now. I thought it the change is was an
improvement but apparently not.
I'm doing more changes to this code, but it's not ready to commit yet.
Jose
From: Thomas Hellström [tho...@shipmail.org]
Sent: Monday, January 11,
On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
> A better fix should be to make sure the exaMoveInPixmap() call is before
> the exaGetPixmapDriverPrivate() call. The latter should never return
> NULL then (unless we run out of resources maybe - might be worth keeping
> the checks for that)
Luca Barbieri writes:
> I thought MSVC supported C99, but that seems not to be the case.
>
> However, it seems to have partial C99 support, and according to MSDN
> the particular case of for loop initializers C99 behaviour may be
> selected with /Zc:forScope.
Wow, I never knew about that option.
Jose,
Your commit
5b64d94390e4805e1634f0c8b5e3156e12b8b872, pipebuffer: Multi-threading
fixes for fencing
Makes the Xorg state-tracker deadlock at startup with the following
backtrace, on mesa_7_7_branch.
/Thomas
0x7fd15d3bd6a4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x000
On Mon, 2010-01-11 at 14:56 -0800, Zack Rusin wrote:
> Module: Mesa
> Branch: mesa_7_7_branch
> Commit: 3447d545d99c450c6a13d8a37e9cb9f5463a40eb
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=3447d545d99c450c6a13d8a37e9cb9f5463a40eb
>
> Author: Zack Rusin
> Date: Mon Jan 11 18:0
On 11 jan 2010, at 21.17, Zack Rusin wrote:
> On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
>> On 11 jan 2010, at 17.49, Zack Rusin wrote:
>>> I think the other stuff is acceptable. Take a look at the docs and
>>> let me know
>>> what you think.
>>
>> Hmm I don't think you should re
I thought MSVC supported C99, but that seems not to be the case.
However, it seems to have partial C99 support, and according to MSDN
the particular case of for loop initializers C99 behaviour may be
selected with /Zc:forScope.
I can't find any reference on exactly which parts of C99 are supporte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zack Rusin wrote:
> On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
>> On 11 jan 2010, at 17.49, Zack Rusin wrote:
>>> I think the other stuff is acceptable. Take a look at the docs and
>>> let me know
>>> what you think.
>> Hmm I don't thi
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
> On 11 jan 2010, at 17.49, Zack Rusin wrote:
> > I think the other stuff is acceptable. Take a look at the docs and
> > let me know
> > what you think.
>
> Hmm I don't think you should remove the CAPs but instead just say if
> level X th
On Monday 11 January 2010 15:22:43 Luca Barbieri wrote:
> The feature levels in the attached table don't apply exactly to all
> hardware.
>
> For instance:
> 1. Two sided stencil is supported from NV30/GeForce FX
> 2. Triangle fans and point sprites are supported in hardware on NV50
> (according
On 11 jan 2010, at 17.49, Zack Rusin wrote:
> Hey,
>
> knowing that we're starting to have serious issues with figuring out
> what
> features the given device supports and what api's/extensions can be
> reasonably
> implemented on top of it I've spent the weekend trying to define
> feature
>
On Monday 11 January 2010 15:17:00 Roland Scheidegger wrote:
> > - extra mirror wrap modes - i don't think mirror repeat was ever
> > supported and mirror clamp was removed in d3d10 but it seems that some
> > hardware kept support for those
>
> Mirror repeat is a core feature in GL since 1.4 hence
On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote:
> On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote:
> > > The reason why I didn't implement the glX*Gallium*Mesa functions is
> > > because the glx* extensions are implemented by libGL, and a driver
> > > driver never has chance to expor
On Mon, 2010-01-11 at 12:42 -0800, Luca Barbieri wrote:
> > But for Mesa core and shared Gallium code, we target portability and
> > that means pretty strict C90...
>
> Well, then maybe -std=c99 should be removed from the global config and
> put in driver Makefiles.
Yes, that's a good idea.
> An
> But for Mesa core and shared Gallium code, we target portability and
> that means pretty strict C90...
Well, then maybe -std=c99 should be removed from the global config and
put in driver Makefiles.
Anyway, it's not obvious that anyone is using a non-C99 compiler to
compile Mesa, and they could
The feature levels in the attached table don't apply exactly to all hardware.
For instance:
1. Two sided stencil is supported from NV30/GeForce FX
2. Triangle fans and point sprites are supported in hardware on NV50
(according to Nouveau registers)
3. Alpha-to-coverage should be supported on R300
On 11.01.2010 18:49, Zack Rusin wrote:
> Hey,
>
> knowing that we're starting to have serious issues with figuring out what
> features the given device supports and what api's/extensions can be
> reasonably
> implemented on top of it I've spent the weekend trying to define feature
> levels. Fe
On Mon, 2010-01-11 at 11:19 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> José Fonseca wrote:
> > Attached is a patch that generalizes the ALIGN16/8_XXX macros in
> > p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
> > bytes.
> >
> > There is
On Mon, 2010-01-11 at 11:18 -0800, Luca Barbieri wrote:
> > gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
> > -I../../src/gallium/auxiliary -Wall -Wmissing-prototypes
> > -Wdeclaration-after-statement -Wpointer-arith -g -fPIC -D_POSIX_SOURCE
> > -D_POSIX_C_SOURCE=199309L -
On Mon, 2010-01-11 at 11:14 -0800, Brian Paul wrote:
> Keith Whitwell wrote:
> > Module: Mesa
> > Branch: gallium-fb-dimensions
> > Commit: 609b043d442c99e48d5310244e648ea8a6cc2e8a
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=609b043d442c99e48d5310244e648ea8a6cc2e8a
> >
> > Au
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
> Attached is a patch that generalizes the ALIGN16/8_XXX macros in
> p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
> bytes.
>
> There is more than one way to have cross-platform alignment macros --
> all quite
If that's the case, then I will patch the kernel to not be such a crybaby.
Posting from a mobile, pardon my terseness. ~ C.
On Jan 11, 2010 11:20 AM, "Marek Olšák" wrote:
It was NOT intended to be a performance optimization, it's a fix. I added it
because kernel would have rejected the command
It was NOT intended to be a performance optimization, it's a fix. I added it
because kernel would have rejected the command stream if everything had been
culled by scissoring.
Marek
On Mon, Jan 11, 2010 at 4:39 PM, Corbin Simpson
wrote:
> Pardon the subject pun, it was totally necessary at this
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
> -I../../src/gallium/auxiliary -Wall -Wmissing-prototypes
> -Wdeclaration-after-statement -Wpointer-arith -g -fPIC -D_POSIX_SOURCE
> -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE
> -DPTHREADS -DUSE_XS
Keith Whitwell wrote:
> On Mon, 2010-01-11 at 07:39 -0800, Corbin Simpson wrote:
>> Pardon the subject pun, it was totally necessary at this early hour. :3
>>
>> If the scissor test is enabled, and the scissors obscure the entire
>> framebuffer, should drawing calls still be run?
If the scissor bo
On Mon, 2010-01-11 at 09:36 -0800, Igor Oliveira wrote:
> Right,
>
> Doing it.
Thanks Igor.
Keith
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app devel
Hello,
On Mon, Jan 11, 2010 at 1:54 PM, michal wrote:
> Igor Oliveira wrote on 2010-01-11 14:37:
>>
>> These patches add support to double opcodes as discussed in mail list.
>> The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
>> dmuladd, drcp and dslt.
>> They are used like sugge
Igor Oliveira wrote on 2010-01-11 14:37:
> These patches add support to double opcodes as discussed in mail list.
> The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
> dmuladd, drcp and dslt.
> They are used like suggested by Zack:
>
> MOVD A.xy, C.xy, c.xy
>
> where x is the lsb an
Hey,
knowing that we're starting to have serious issues with figuring out what
features the given device supports and what api's/extensions can be reasonably
implemented on top of it I've spent the weekend trying to define feature
levels. Feature levels were effectively defined by the Direct3D
Ok
Igor
On Mon, Jan 11, 2010 at 10:37 AM, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
>> +OP13(DMULADD)
>
> For consistency with the existing opcodes, would it be better to have
> DMAD here?
>
> Keith
>
>
--
Right,
Doing it.
On Mon, Jan 11, 2010 at 10:15 AM, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
>> These patches add support to double opcodes as discussed in mail list.
>> The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
>> dmuladd, drcp and d
On 11.01.2010 16:53, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 07:50 -0800, Roland Scheidegger wrote:
>> On 11.01.2010 16:42, Keith Whitwell wrote:
>>> On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simp
http://bugs.freedesktop.org/show_bug.cgi?id=21979
--- Comment #4 from Przemyslaw.szczepaniak
2010-01-11 08:15:42 PST ---
Created an attachment (id=32569)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32569)
Fix for glBlendEquationSeparate
glBlendEquationSeparate/glBlendEquationSepara
On Mon, 2010-01-11 at 07:50 -0800, Roland Scheidegger wrote:
> On 11.01.2010 16:42, Keith Whitwell wrote:
> > On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
> >> Hi,
> >>
> >> I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
> >> change, so things should continue
On Mon, 2010-01-11 at 07:39 -0800, Corbin Simpson wrote:
> Pardon the subject pun, it was totally necessary at this early hour. :3
>
> If the scissor test is enabled, and the scissors obscure the entire
> framebuffer, should drawing calls still be run? Talking on IRC, it
> seems like there's a val
On 11.01.2010 16:42, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
>> Hi,
>>
>> I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
>> change, so things should continue to run :-).
>
> Roland,
>
> Before you do this, can you make sure that
On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
> Hi,
>
> I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
> change, so things should continue to run :-).
Roland,
Before you do this, can you make sure that the set_constant_buffer()
entrypoint is properly documen
Pardon the subject pun, it was totally necessary at this early hour. :3
If the scissor test is enabled, and the scissors obscure the entire
framebuffer, should drawing calls still be run? Talking on IRC, it
seems like there's a valid use-case for performance testing, and I'm
of the mind that anybo
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizo
2010/1/10 Chia-I Wu :
> Hi Kristian,
>
> I found there are some more breakages after -fvisibility=hidden in
> Gallium state trackers. This patch series marks 3 APIs public
>
> * OpenVG API (patch 1)
> * st_public.h (patch 3)
> * GLX API in GLX state tracker (patch 4)
>
> I am working on a new EGL
On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
> +OP13(DMULADD)
For consistency with the existing opcodes, would it be better to have
DMAD here?
Keith
--
This SF.Net email is sponsored by the Verizon Developer
On 8 jan 2010, at 18.42, Mike Stroyan wrote:
On Thu, Jan 7, 2010 at 4:34 AM, Keith Whitwell
wrote:
It looks like there are some unrelated changes in your diff -- can you
separate them out into disjoint changes? One way is to make several
commits to your local git repo and then use git-format
On Mon, 2010-01-11 at 05:37 -0800, Igor Oliveira wrote:
> These patches add support to double opcodes as discussed in mail list.
> The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
> dmuladd, drcp and dslt.
> They are used like suggested by Zack:
>
> MOVD A.xy, C.xy, c.xy
>
> wher
These patches add support to double opcodes as discussed in mail list.
The opcodes create are: movd, ddiv, dadd, dseq, dmax, dmin, dmul,
dmuladd, drcp and dslt.
They are used like suggested by Zack:
MOVD A.xy, C.xy, c.xy
where x is the lsb and y is the msb.
There are still missing some opcodes b
On Sun, 2010-01-10 at 05:26 -0800, José Fonseca wrote:
> Attached is a patch that generalizes the ALIGN16/8_XXX macros in
> p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
> bytes.
>
> There is more than one way to have cross-platform alignment macros --
> all quite ugly.
>
> T
On Sun, 2010-01-10 at 12:04 -0800, Luca Barbieri wrote:
> + {
> + char* dst = texImage->Data;
> + char* src = pixels;
> + for(int i = 0; i < height; ++i)
> + {
> +memcpy(dst, src, srcImageStride);
> +dst += dstRowStride;
> +sr
On Fri, 2010-01-08 at 21:44 -0800, Vinson Lee wrote:
> Module: Mesa
> Branch: mesa_7_7_branch
> Commit: 4775723d2f641dcd82e8c9cd39ba52f8d86158c7
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4775723d2f641dcd82e8c9cd39ba52f8d86158c7
>
> Author: Vinson Lee
> Date: Fri Jan 8 21:4
66 matches
Mail list logo
