Menu
▾
▴
mesa3d-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(10) |
Apr
(28) |
May
(41) |
Jun
(91) |
Jul
(63) |
Aug
(45) |
Sep
(37) |
Oct
(80) |
Nov
(91) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(48) |
Feb
(121) |
Mar
(126) |
Apr
(16) |
May
(85) |
Jun
(84) |
Jul
(115) |
Aug
(71) |
Sep
(27) |
Oct
(33) |
Nov
(15) |
Dec
(71) |
| 2002 |
Jan
(73) |
Feb
(34) |
Mar
(39) |
Apr
(135) |
May
(59) |
Jun
(116) |
Jul
(93) |
Aug
(40) |
Sep
(50) |
Oct
(87) |
Nov
(90) |
Dec
(32) |
| 2003 |
Jan
(181) |
Feb
(101) |
Mar
(231) |
Apr
(240) |
May
(148) |
Jun
(228) |
Jul
(156) |
Aug
(49) |
Sep
(173) |
Oct
(169) |
Nov
(137) |
Dec
(163) |
| 2004 |
Jan
(243) |
Feb
(141) |
Mar
(183) |
Apr
(364) |
May
(369) |
Jun
(251) |
Jul
(194) |
Aug
(140) |
Sep
(154) |
Oct
(167) |
Nov
(86) |
Dec
(109) |
| 2005 |
Jan
(176) |
Feb
(140) |
Mar
(112) |
Apr
(158) |
May
(140) |
Jun
(201) |
Jul
(123) |
Aug
(196) |
Sep
(143) |
Oct
(165) |
Nov
(158) |
Dec
(79) |
| 2006 |
Jan
(90) |
Feb
(156) |
Mar
(125) |
Apr
(146) |
May
(169) |
Jun
(146) |
Jul
(150) |
Aug
(176) |
Sep
(156) |
Oct
(237) |
Nov
(179) |
Dec
(140) |
| 2007 |
Jan
(144) |
Feb
(116) |
Mar
(261) |
Apr
(279) |
May
(222) |
Jun
(103) |
Jul
(237) |
Aug
(191) |
Sep
(113) |
Oct
(129) |
Nov
(141) |
Dec
(165) |
| 2008 |
Jan
(152) |
Feb
(195) |
Mar
(242) |
Apr
(146) |
May
(151) |
Jun
(172) |
Jul
(123) |
Aug
(195) |
Sep
(195) |
Oct
(138) |
Nov
(183) |
Dec
(125) |
| 2009 |
Jan
(268) |
Feb
(281) |
Mar
(295) |
Apr
(293) |
May
(273) |
Jun
(265) |
Jul
(406) |
Aug
(679) |
Sep
(434) |
Oct
(357) |
Nov
(306) |
Dec
(478) |
| 2010 |
Jan
(856) |
Feb
(668) |
Mar
(927) |
Apr
(269) |
May
(12) |
Jun
(13) |
Jul
(6) |
Aug
(8) |
Sep
(23) |
Oct
(4) |
Nov
(8) |
Dec
(11) |
| 2011 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: George S. <gsa...@gm...> - 2010-02-23 03:12:13
|
On Tue, Feb 23, 2010 at 4:20 AM, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > George Sapountzis wrote: >> Hi, >> >> I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv >> the code generation functionality in the gen subdir. >> >> Please review, > > I'm curious... what is the reason for these changes? > > I do like the addition of the MESA_DIR and MESA_GLX_DIR variables. I > also like the change of GLX_DIR to XORG_GLX_DIR. Patches making those > changes could probably go in right away. I'd like a little explanation > of why everything should be moved to a subdirectory before doing that. It does not move everything, but the API xml files and code generation scripts. So, it is a clean-up that separates the code linked with libGL from the code generation infrastructure. The result looks cleaner here, so I'd like to push that as well if not strongly opposed. Thanks for the review, George. |
|
From: Marek O. <ma...@gm...> - 2010-02-23 02:52:26
|
On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul <bri...@gm...> wrote: > On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák <ma...@gm...> wrote: > > Hi, > > > > the attached patch modifies st/dri to not enable EXT_draw_buffers2 by > > default because r300g and most probably even some other drivers can't > > support this extension. The drivers reporting support of > > PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. > > > > Please review. > > Hmm, I believe the extensions listed in dri_extensions.c are those > that _may_ be supported by drivers. But its the st_extensions.c code > that queries the driver for various caps (such as > PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if > applicable. > I stand corrected. > > Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g? > Unfortunately yes, it is. -Marek |
|
From: Ian R. <id...@fr...> - 2010-02-23 02:48:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Romanick wrote: > Brian Paul wrote: >> I think we could get by with a shorter "beta" period. There's a few >> more things that would be nice to do for 7.8 which I doubt I'd get to >> before the 26th: > > Part of the reason for the long lead time is to keep my testing group > happy. I don't see a problem moving the branch out a week (to 3/5). > I'll check with them to be sure. I just talked to my QA team leader. Since it doesn't look like any of the proposed changes will impact testing our drivers, he's okay pushing branch creation out a week. I'll plan to make the 7.8 branch on 3/5 instead of 2/26. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuDOWEACgkQX1gOwKyEAw9VGQCgj6CwhfgV2g3IJ0qlEwjbYiw5 DfkAn11TltX3pc0sGtZDeFut6pRDgsrv =oBL7 -----END PGP SIGNATURE----- |
|
From: Ian R. <id...@fr...> - 2010-02-23 02:48:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Sapountzis wrote: > Hi, > > I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv > the code generation functionality in the gen subdir. > > Please review, I'm curious... what is the reason for these changes? I do like the addition of the MESA_DIR and MESA_GLX_DIR variables. I also like the change of GLX_DIR to XORG_GLX_DIR. Patches making those changes could probably go in right away. I'd like a little explanation of why everything should be moved to a subdirectory before doing that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuDO30ACgkQX1gOwKyEAw88fgCfTk0Y0CRTA0gphCENtx9KVbfE gP4AnRkZnRb92JNYu5ebB3wQwW3faO8j =6t7B -----END PGP SIGNATURE----- |
|
From: <dem...@ne...> - 2010-02-23 00:55:02
|
-----Original Message----- From: Ian Romanick <id...@fr...> To: mes...@li... <mes...@li...> Sent: Mon, Feb 22, 2010 1:46 pm Subject: Re: [Mesa3d-dev] Mesa removals -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Starting a new thread on this... > > Here's a proposal of things to remove from the Mesa tree. > > GLU: > glu/mini > glu/mesa > > GLUT: > glut/fbdev > glut/ggi > glut/directfb > glut/dos > glut/mini > glut/os2 > > non-DRI drivers: > drivers/allegro > drivers/directfb > drivers/d3d > drivers/dos > drivers/ggi > drivers/glide > drivers/svga > > DRI drivers: > drivers/dri/fb > drivers/dri/ffb > drivers/dri/gamma > > progs/directfb > progs/ggi > progs/windml > progs/miniglx > > Comments? That list looks good to me. I'm a little sad to see gamma go, but that's mostly sadness that it was never revived after the DRI / DRM architecture started going a different direction. Does anyone have docs for gamma hardware? If so, I'd love to get my hands on it. I still have a gamma board that needs a bit of love! Dee Sharpe |
|
From: Dave A. <ai...@gm...> - 2010-02-22 22:42:40
|
> > I'm actually in the process of gathering hardware to revive gamma (or > rewrite its stack all together). > > So I don't know whether it should be removed or not. Certainly the > mesa component of the stack won't be touched until I get a memory > manager working. I suspect any attempt at reviviing it will need a 3D driver re-write anyways. Since it heavily relies on the dma scheme it used. Dave. |
|
From: Matt T. <mat...@gm...> - 2010-02-22 21:42:09
|
On Mon, Feb 22, 2010 at 2:46 PM, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: >> Starting a new thread on this... >> >> Here's a proposal of things to remove from the Mesa tree. >> >> GLU: >> glu/mini >> glu/mesa >> >> GLUT: >> glut/fbdev >> glut/ggi >> glut/directfb >> glut/dos >> glut/mini >> glut/os2 >> >> non-DRI drivers: >> drivers/allegro >> drivers/directfb >> drivers/d3d >> drivers/dos >> drivers/ggi >> drivers/glide >> drivers/svga >> >> DRI drivers: >> drivers/dri/fb >> drivers/dri/ffb >> drivers/dri/gamma >> >> progs/directfb >> progs/ggi >> progs/windml >> progs/miniglx >> >> Comments? > > That list looks good to me. I'm a little sad to see gamma go, but > that's mostly sadness that it was never revived after the DRI / DRM > architecture started going a different direction. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuC3xkACgkQX1gOwKyEAw/Z6wCeNvkBnT3OuCpeoHwHyILe9/TE > 7jAAn3cNRz7pVgz16/xGOBJPd+J3DwsA > =m62D > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev I'm actually in the process of gathering hardware to revive gamma (or rewrite its stack all together). So I don't know whether it should be removed or not. Certainly the mesa component of the stack won't be touched until I get a memory manager working. Matt |
|
From: George S. <gsa...@gm...> - 2010-02-22 20:36:34
|
Hi, I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv the code generation functionality in the gen subdir. Please review, regards, George. |
|
From: Ian R. <id...@fr...> - 2010-02-22 19:47:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Starting a new thread on this... > > Here's a proposal of things to remove from the Mesa tree. > > GLU: > glu/mini > glu/mesa > > GLUT: > glut/fbdev > glut/ggi > glut/directfb > glut/dos > glut/mini > glut/os2 > > non-DRI drivers: > drivers/allegro > drivers/directfb > drivers/d3d > drivers/dos > drivers/ggi > drivers/glide > drivers/svga > > DRI drivers: > drivers/dri/fb > drivers/dri/ffb > drivers/dri/gamma > > progs/directfb > progs/ggi > progs/windml > progs/miniglx > > Comments? That list looks good to me. I'm a little sad to see gamma go, but that's mostly sadness that it was never revived after the DRI / DRM architecture started going a different direction. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuC3xkACgkQX1gOwKyEAw/Z6wCeNvkBnT3OuCpeoHwHyILe9/TE 7jAAn3cNRz7pVgz16/xGOBJPd+J3DwsA =m62D -----END PGP SIGNATURE----- |
|
From: Keith P. <ke...@ke...> - 2010-02-22 18:51:02
|
> Please commit to both master and mesa_7_7_branch. Thanks. mesa_7_7_branch doesn't use 'cd' in mklib. -- kei...@in... |
|
From: Brian P. <br...@vm...> - 2010-02-22 18:08:32
|
Corbin wrote: > Glide is a GL->glide driver, right? So it is not needed for libglide apps? Yes, correct. -Brian |
|
From: Corbin S. <mos...@gm...> - 2010-02-22 18:04:57
|
Glide is a GL->glide driver, right? So it is not needed for libglide apps? Posting from a mobile, pardon my terseness. ~ C. On Feb 22, 2010 8:40 AM, "Brian Paul" <br...@vm...> wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? -Brian ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mes...@li... https://lists.sourceforge.net/lists/listinfo/mesa3d-dev |
|
From: Brian P. <br...@vm...> - 2010-02-22 16:38:58
|
Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? -Brian |
|
From: Dan N. <dbn...@gm...> - 2010-02-22 16:27:42
|
On Mon, Feb 22, 2010 at 7:17 AM, Brian Paul <bri...@gm...> wrote: > On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson <dbn...@gm...> wrote: >> On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard <ke...@ke...> wrote: >>> The bash 'cd' command tends to emit random stuff to stdout when the >>> CDPATH variable is set, so clear it to keep extra filenames from being >>> emitted from the expand_archive function, which would otherwise cause >>> mklib to fail. >>> >>> Signed-off-by: Keith Packard <ke...@ke...> >> >> Congratulations on wading in to mklib, it's not a friendly place. :) > > Heh, I guess you've never had to debug libtool then. mklib is a walk > in the park by comparison. Sorry, didn't mean to imply that it's simplicity is not a virtue. On the other hand, it doesn't get a ton of love, so it tends to be pretty incoherent. libtool debugging is an absolute nightmare, but thankfully it's been a long time since most people had to deal with that. -- Dan |
|
From: Nathan K. <nat...@sp...> - 2010-02-22 16:26:22
|
On 10-02-19 07:16 PM, Ian Romanick wrote: > While we're on the topic of removing dead weight, can we remove support > for color index rendering? None of the hardware drivers support color > index rendering, and color index rendering is deprecated in OpenGL 3.0 > (and removed in 3.1). > > Can it please die in a fire? As a workaround if someone really wants CI rendering, one can use VirtualGL to provide a CI visual on RGB-only hardware. -Nathan |
|
From: Daniel S. <da...@fo...> - 2010-02-22 16:08:18
|
On Mon, Feb 22, 2010 at 08:17:31AM -0700, Brian Paul wrote: > On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson <dbn...@gm...> wrote: > > On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard <ke...@ke...> wrote: > >> The bash 'cd' command tends to emit random stuff to stdout when the > >> CDPATH variable is set, so clear it to keep extra filenames from being > >> emitted from the expand_archive function, which would otherwise cause > >> mklib to fail. > >> > >> Signed-off-by: Keith Packard <ke...@ke...> > > > > Congratulations on wading in to mklib, it's not a friendly place. :) > > Heh, I guess you've never had to debug libtool then. mklib is a walk > in the park by comparison. In fairness though, I haven't had to debug libtool for several years now, because it always seems to work, whereas mklib seems to encounter new and exciting failures all the time. Oh well. :) Cheers, Daniel |
|
From: Eric A. <er...@an...> - 2010-02-22 16:03:54
|
On Fri, 19 Feb 2010 16:16:32 -0800, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While we're on the topic of removing dead weight, can we remove support > for color index rendering? None of the hardware drivers support color > index rendering, and color index rendering is deprecated in OpenGL 3.0 > (and removed in 3.1). > > Can it please die in a fire? I don't see any plausible justification for CI rendering support. I'd love to see it die. |
|
From: Brian P. <bri...@gm...> - 2010-02-22 15:54:22
|
On Sat, Feb 20, 2010 at 9:32 AM, Xavier Chantry <cha...@gm...> wrote: > On Sat, Feb 20, 2010 at 5:22 PM, Brian Paul <bri...@gm...> wrote: >> On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry >> <cha...@gm...> wrote: >>> It seems the commit below will always report an user error when >>> glxinfo -l is called. >>> And indeed I always get the following : >>> $ glxinfo -l >>> ... >>> GL_VERTEX_PROGRAM_ARB: >>> ... >>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) >>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) >>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) >>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) >>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) >>> Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) >>> >>> Should glxinfo be fixed to avoid this error ? >>> We could just put the fragment program only parameter in its own list, >>> and not use them when target is vertex program. >> >> Well, normally GL errors aren't reported to stderr so most people >> running non-debug builds won't see those. But yeah, we probably >> shouldn't generate the errors anyway. Feel free to write a patch to >> glxinfo... >> > > I only realized yesterday that non-debug was the reason other people > (and some of my systems) didn't show these errors. It had been bugging > me for a while :) > > Attached patch should fix it. Thanks. I'll commit it soon. -Brian |
|
From: Brian P. <bri...@gm...> - 2010-02-22 15:34:31
|
On Fri, Feb 19, 2010 at 5:16 PM, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While we're on the topic of removing dead weight, can we remove support > for color index rendering? None of the hardware drivers support color > index rendering, and color index rendering is deprecated in OpenGL 3.0 > (and removed in 3.1). > > Can it please die in a fire? I think it can probably go. I haven't tested CI mode rendering in many years. Who knows if it even works any more. -Brian |
|
From: Roland S. <sr...@vm...> - 2010-02-22 15:29:50
|
Marek,
I don't particularly like that patch, because it doesn't really fix the
problem with the extension handling.
There are lots of extension listed there which should not be advertized
by default, so picking one out won't fix the others.
I think they are there because driInitExtensions definitely does more
than just set ctx->Extensions_foo_bar to enable.
Other extensions in this list which are queried by CAP bits but still
show up in the extension string regardless are the glsl ones
(ARB_fragment_shader and friends), a couple texture address modes
(mirrored_repeat, mirror_clamp), blend_equation_separate, technically
even ARB_multitexture (though we probably should skip the test for more
than 1 texture unit and always set that to true in st_extensions.c),
two-sided stencil, occlusion queries, anisotropic filtering, ycbcr
textures, packed depth stencil (there may be more that was just from a
quick look).
So if it's ok to remove them all from that list this should be done, but
I fear it's not ok and the fix needs to be a bit more complicated (see
comments in dri_init_extensions).
Roland
On 21.02.2010 16:00, Marek Olšák wrote:
> Hi,
>
> the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
> default because r300g and most probably even some other drivers can't
> support this extension. The drivers reporting support of
> PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
>
> Please review.
>
> Marek
>
>
> ------------------------------------------------------------------------
>
> From ddda2c19b74780263f848ffafe10809bd6385d01 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= <ma...@gm...>
> Date: Sun, 21 Feb 2010 01:27:09 +0100
> Subject: [PATCH 2/2] st/dri: don't enable EXT_draw_buffers2 by default
>
> ---
> src/gallium/state_trackers/dri/dri_extensions.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri_extensions.c b/src/gallium/state_trackers/dri/dri_extensions.c
> index 1259813..7f8ceef 100644
> --- a/src/gallium/state_trackers/dri/dri_extensions.c
> +++ b/src/gallium/state_trackers/dri/dri_extensions.c
> @@ -99,7 +99,6 @@ static const struct dri_extension card_extensions[] = {
> {"GL_EXT_blend_minmax", GL_EXT_blend_minmax_functions},
> {"GL_EXT_blend_subtract", NULL},
> {"GL_EXT_cull_vertex", GL_EXT_cull_vertex_functions},
> - {"GL_EXT_draw_buffers2", GL_EXT_draw_buffers2_functions},
> {"GL_EXT_fog_coord", GL_EXT_fog_coord_functions},
> {"GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions},
> {"GL_EXT_multi_draw_arrays", GL_EXT_multi_draw_arrays_functions},
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
|
|
From: Brian P. <bri...@gm...> - 2010-02-22 15:23:20
|
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák <ma...@gm...> wrote: > Hi, > > the attached patch modifies st/dri to not enable EXT_draw_buffers2 by > default because r300g and most probably even some other drivers can't > support this extension. The drivers reporting support of > PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. > > Please review. Hmm, I believe the extensions listed in dri_extensions.c are those that _may_ be supported by drivers. But its the st_extensions.c code that queries the driver for various caps (such as PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if applicable. Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g? -Brian |
|
From: Brian P. <bri...@gm...> - 2010-02-22 15:17:37
|
On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson <dbn...@gm...> wrote: > On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard <ke...@ke...> wrote: >> The bash 'cd' command tends to emit random stuff to stdout when the >> CDPATH variable is set, so clear it to keep extra filenames from being >> emitted from the expand_archive function, which would otherwise cause >> mklib to fail. >> >> Signed-off-by: Keith Packard <ke...@ke...> > > Congratulations on wading in to mklib, it's not a friendly place. :) Heh, I guess you've never had to debug libtool then. mklib is a walk in the park by comparison. -Brian |
|
From: Brian P. <bri...@gm...> - 2010-02-22 15:16:58
|
On Sun, Feb 21, 2010 at 3:33 PM, Keith Packard <ke...@ke...> wrote: > The bash 'cd' command tends to emit random stuff to stdout when the > CDPATH variable is set, so clear it to keep extra filenames from being > emitted from the expand_archive function, which would otherwise cause > mklib to fail. > > Signed-off-by: Keith Packard <ke...@ke...> Signed-off-by: Brian Paul <br...@vm...> Please commit to both master and mesa_7_7_branch. Thanks. -Brian |
|
From: <bug...@fr...> - 2010-02-22 15:15:13
|
http://bugs.freedesktop.org/show_bug.cgi?id=26692 Brian Paul <bri...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Brian Paul <bri...@gm...> 2010-02-22 07:15:04 PST --- Fixed with commits 98e2f6c38bede8373fbf51981ccf6b513ac3695c and 2467354842d7118efff73165ddaaf4c519b41e46. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: José F. <jfo...@vm...> - 2010-02-22 14:56:56
|
The pipebuffer library works well with purely user space suballocation of a big pinned buffer, but there are some further tweaks necessary in order to use it with kernel TTM-like memory managers. For example, one problem with pb_bufmgr_cache is that it doesn't try to check if a buffer is busy (e.g., by trying to map with PIPE_BUFFER_USAGE_DONTBLOCK) before reusing it. This worked fine so far because fencing was implemented on top of buffer suballocation and caching (ie., by the time a freed buffer was put in the cache list it was already guaranteed to have no pending fences). But this is not true if caching is used by itself on top of a kernel memory manager. Thomas also noticed the way validation lists works also needs some tweaks in order to work correctly. I don't think there's anything fundamentally broken in pipebuffer lib, just that we never had the need to make fix it so far. Jose On Sun, 2010-02-21 at 23:29 -0800, Dave Airlie wrote: > Module: Mesa > Branch: master > Commit: b14548ea32000459f4f0c4b49f3fa11d1ee9c003 > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b14548ea32000459f4f0c4b49f3fa11d1ee9c003 > > Author: Dave Airlie <ai...@re...> > Date: Mon Feb 22 17:26:30 2010 +1000 > > Revert "r300g: rebuild winsys/pipe buffer handling and add buffer map" > > This reverts commit fff5be8e7b4557c221f2425dcafc2e7cbbba76ba. > > Probably went too soon with this, dileX reported OA not working for him > it works here fine, but the optimisations I wanted aren't working properly > yet so I'll fix that now. > > Signed-off-by: Dave Airlie <ai...@re...> > > --- > > src/gallium/drivers/r300/Makefile | 1 - > src/gallium/drivers/r300/r300_context.c | 38 +-- > src/gallium/drivers/r300/r300_context.h | 9 +- > src/gallium/drivers/r300/r300_cs.h | 22 +- > src/gallium/drivers/r300/r300_emit.c | 54 ++-- > src/gallium/drivers/r300/r300_render.c | 33 +-- > src/gallium/drivers/r300/r300_screen.c | 38 +-- > src/gallium/drivers/r300/r300_screen.h | 2 +- > src/gallium/drivers/r300/r300_screen_buffer.c | 222 ------------ > src/gallium/drivers/r300/r300_screen_buffer.h | 85 ----- > src/gallium/drivers/r300/r300_state.c | 25 +-- > src/gallium/drivers/r300/r300_texture.c | 41 +-- > src/gallium/drivers/r300/r300_texture.h | 4 +- > src/gallium/drivers/r300/r300_winsys.h | 127 +------- > src/gallium/winsys/drm/i965/gem/i965_drm_winsys.h | 2 + > src/gallium/winsys/drm/radeon/core/Makefile | 2 +- > src/gallium/winsys/drm/radeon/core/radeon_buffer.h | 60 ++-- > src/gallium/winsys/drm/radeon/core/radeon_drm.c | 134 +++++--- > src/gallium/winsys/drm/radeon/core/radeon_drm.h | 5 + > .../winsys/drm/radeon/core/radeon_drm_buffer.c | 361 -------------------- > src/gallium/winsys/drm/radeon/core/radeon_r300.c | 237 ++++---------- > src/gallium/winsys/drm/radeon/core/radeon_r300.h | 6 +- > src/gallium/winsys/drm/radeon/core/radeon_winsys.h | 86 +++-- > 23 files changed, 347 insertions(+), 1247 deletions(-) > > Diff: http://cgit.freedesktop.org/mesa/mesa/diff/?id=b14548ea32000459f4f0c4b49f3fa11d1ee9c003 > _______________________________________________ > mesa-commit mailing list > mes...@li... > http://lists.freedesktop.org/mailman/listinfo/mesa-commit |
102 messages has been excluded from this view by a project administrator.
