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: <bug...@fr...> - 2010-03-23 14:46:07
|
http://bugs.freedesktop.org/show_bug.cgi?id=27261 --- Comment #5 from Brian Paul <bri...@gm...> 2010-03-23 07:46:01 PST --- (In reply to comment #4) > I will try the latest release candidate and see if the problem has been fixed. > I have also been observing random failures in the GLES conformance suite when I > run with MESA. Has there been some memory leaks etc fixed in the new release? I don't know what would cause random failures. Every so often I find/fix memory leaks but I don't know if that would be related to your issue. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-03-23 14:38:36
|
http://bugs.freedesktop.org/show_bug.cgi?id=27261 --- Comment #4 from Karthik Hariharakrishnan <kar...@ar...> 2010-03-23 07:38:08 PST --- (In reply to comment #3) > The fragment shader / preprocessor bug has been fixed for Mesa 7.8. > > I probably won't get around to the other bugs for a while. I really wish the > GLSL didn't allow all those goofy constructors. They're really hard to > implement and real shaders seldom use them. > I will try the latest release candidate and see if the problem has been fixed. I have also been observing random failures in the GLES conformance suite when I run with MESA. Has there been some memory leaks etc fixed in the new release? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-03-23 14:34:12
|
http://bugs.freedesktop.org/show_bug.cgi?id=27265 --- Comment #2 from Karthik Hariharakrishnan <kar...@ar...> 2010-03-23 07:34:03 PST --- Created an attachment (id=34367) --> (http://bugs.freedesktop.org/attachment.cgi?id=34367) fragment shader used in main.c -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-03-23 14:33:45
|
http://bugs.freedesktop.org/show_bug.cgi?id=27265 --- Comment #1 from Karthik Hariharakrishnan <kar...@ar...> 2010-03-23 07:33:37 PST --- Created an attachment (id=34366) --> (http://bugs.freedesktop.org/attachment.cgi?id=34366) source code - sample GLES app -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-03-23 14:33:01
|
http://bugs.freedesktop.org/show_bug.cgi?id=27265 Summary: GLSL Compiler doesnt link the attached vertex shader Product: Mesa Version: 7.5 Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Mesa core AssignedTo: mes...@li... ReportedBy: kar...@ar... Created an attachment (id=34365) --> (http://bugs.freedesktop.org/attachment.cgi?id=34365) Vertex Shader that fails to link The attached vertex shader does not link. A call to glGetProgramiv(program, GL_LINK_STATUS, &result)after glLinkProgram returns GL_FALSE. Attaching the code and the shaders. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Sedat D. <sed...@go...> - 2010-03-23 14:16:33
|
Unfortunately, this means to get rid of
$RADEON_CFLAGS
$RADEON_LDFLAGS
in other source files.
As I said I am no autotools expert, but if libdrm_intel does not need
any furher CFLAGS/LDFLAGS, why libdrm_radeon is different?
The benefit of "simplifying" would mean to have libdrm_{intel,radeon}
handled the same way in configure.ac.
I have sent a V2 of my proposals with really checking for
$LIBDRM_RADEON_REQUIRED (keeping $RADEON_CFLAGS and $RADEON_LDFLAGS).
--
Sedat
On Tue, Mar 23, 2010 at 3:02 PM, Luc Verhaegen <li...@sk...> wrote:
> On Tue, Mar 23, 2010 at 02:16:03PM +0100, Sedat Dilek wrote:
>> Hi,
>>
>> what do you think about this proposal?
>>
>> --
>> Sedat
>
> Makes _a_ _lot_ of sense.
>
> Luc Verhaegen.
>
|
|
From: <bug...@fr...> - 2010-03-23 14:15:39
|
http://bugs.freedesktop.org/show_bug.cgi?id=27261 --- Comment #3 from Brian Paul <bri...@gm...> 2010-03-23 07:15:27 PST --- The fragment shader / preprocessor bug has been fixed for Mesa 7.8. I probably won't get around to the other bugs for a while. I really wish the GLSL didn't allow all those goofy constructors. They're really hard to implement and real shaders seldom use them. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Sedat D. <sed...@go...> - 2010-03-23 14:04:34
|
V2 of my proposal. -- Sedat |
|
From: Luc V. <li...@sk...> - 2010-03-23 14:02:51
|
On Tue, Mar 23, 2010 at 02:16:03PM +0100, Sedat Dilek wrote: > Hi, > > what do you think about this proposal? > > -- > Sedat Makes _a_ _lot_ of sense. Luc Verhaegen. |
|
From: Luca B. <luc...@gm...> - 2010-03-23 13:41:43
|
Do Radeons have a CP command to write an arbitrary value to some place in memory? If so, you may want to use that to implement userspace-accessible fencing in the obvious way and then use the fenced bufmgr, which would do that with no pipebuffer changes and no kernel calls. Otherwise, maybe change the kernel module to write a fence number in an mmapable place on fence irqs? |
|
From: Marek O. <ma...@gm...> - 2010-03-23 13:37:42
|
I've updated the TODO list with the stuff from my private one, in case you guys think there are too few things to do. ;) http://dri.freedesktop.org/wiki/R300ToDo?action=diff -Marek On Tue, Mar 23, 2010 at 8:16 AM, Corbin Simpson <mos...@gm...>wrote: > On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson > <mos...@gm...> wrote: > > Good question. There's a handful of things. Passing piglit might be a > > good goal. Bumping the GL version further up, or solidifying the GLSL > > support, might be good too. > > Oh, and how could I forget this? We have a sizeable todo list: > http://dri.freedesktop.org/wiki/R300ToDo > > ~ C. > > -- > When the facts change, I change my mind. What do you do, sir? ~ Keynes > > Corbin Simpson > <Mos...@gm...> > > > ------------------------------------------------------------------------------ > 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: Sedat D. <sed...@go...> - 2010-03-23 13:16:14
|
Hi, what do you think about this proposal? -- Sedat |
|
From: Sedat D. <sed...@go...> - 2010-03-23 12:58:02
|
Thanks for the turbo fix, but you workarounded the "real" bug.
With my patch I get here in build.log:
...
checking for LIBDRM... yes
...
checking for LIBDRM_RADEON... no
...
With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build
should immediately stop while libdrm package here has version 2.4.18.
BUT, that is not the case!
Intel_drm has in configure.ac:
...
case $DRI_DIRS in
*i915*|*i965*)
PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 2.4.19])
;;
esac
...
radeon_libdrm on the contrary:
...
case $DRI_DIRS in
*radeon*|*r200*|*r300*|*r600*)
PKG_CHECK_MODULES([LIBDRM_RADEON],
[libdrm_radeon libdrm >= $LIBDRM_RADEON_REQUIRED],
HAVE_LIBDRM_RADEON=yes,
HAVE_LIBDRM_RADEON=no)
if test "$HAVE_LIBDRM_RADEON" = yes; then
RADEON_CFLAGS="-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS"
RADEON_LDFLAGS=$LIBDRM_RADEON_LIBS
fi
;;
esac
...
IMO checking for LIBDRM_RADEON_REQUIRED has no real effect, but I am
not an autotools expert.
I am not sure if the LIBDRM_RADEON_REQUIRED part could/should be
handled like in libdrm_intel (...be removed and simplified).
Feedback welcome!
--
Sedat
On Tue, Mar 23, 2010 at 1:41 PM, Marek Olšák <ma...@gm...> wrote:
> Fixed in master without requiring new libdrm.
>
> -Marek
>
> On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek <sed...@go...>
> wrote:
>>
>> Fixes here latest issues with mesa master GIT [1].
>>
>> --
>> Sedat
>>
>> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
>>
>>
>> ------------------------------------------------------------------------------
>> 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: Marek O. <ma...@gm...> - 2010-03-23 12:41:36
|
Fixed in master without requiring new libdrm. -Marek On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek <sed...@go...>wrote: > Fixes here latest issues with mesa master GIT [1]. > > -- > Sedat > > [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2 > > > ------------------------------------------------------------------------------ > 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: <bug...@fr...> - 2010-03-23 12:26:06
|
http://bugs.freedesktop.org/show_bug.cgi?id=27261 --- Comment #2 from Karthik Hariharakrishnan <kar...@ar...> 2010-03-23 05:17:17 PST --- Created an attachment (id=34361) --> (http://bugs.freedesktop.org/attachment.cgi?id=34361) Fragment shader with a lot of preprocessing fails -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-03-23 12:14:20
|
http://bugs.freedesktop.org/show_bug.cgi?id=27261 --- Comment #1 from Karthik Hariharakrishnan <kar...@ar...> 2010-03-23 05:14:07 PST --- Created an attachment (id=34360) --> (http://bugs.freedesktop.org/attachment.cgi?id=34360) Failing Vertex Shader Attaching one more vertex shader that fails -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-03-23 12:11:39
|
http://bugs.freedesktop.org/show_bug.cgi?id=27261 Summary: GLSL Compiler fails on the following vertex shader Product: Mesa Version: 7.5 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Mesa core AssignedTo: mes...@li... ReportedBy: kar...@ar... Created an attachment (id=34359) --> (http://bugs.freedesktop.org/attachment.cgi?id=34359) Failing vertex shader The attached vertex shaders do not compile and link when the GLSL Compiler is used. The version of Mesa used is 7.5.2 and it has been configured with --with-driver=xlib. The above vertex shaders are part of the Open GLES conformance suite supplied by Khronos. These shaders compile when the OpenGL drivers supplied by the GPU vendors(NVIDIA, ATI) are installed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Sedat D. <sed...@go...> - 2010-03-23 12:02:07
|
Fixes here latest issues with mesa master GIT [1]. -- Sedat [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2 |
|
From: Sedat D. <sed...@go...> - 2010-03-23 11:49:34
|
Hi, I was trying to compile latest mesa master GIT: commit 2a3accb r300g: fix glean occlusion query test Unfortunately, the build breaks (see below "investigations"). I suspect the cause is I have here Debian's libdrm-2.4.18 installed. "radeon: add square-tiling flag" in [1] was post-2.4.18. So the depends should be bumped to libdrm >=2.4.19. [configure.ac] ... -LIBDRM_RADEON_REQUIRED=2.4.17 +LIBDRM_RADEON_REQUIRED=2.4.19 ... [/configure.ac] Kind Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/drm/commit/?id=4b6f70f20cbaccb18f122e87ac0d471356b01a59 ----- INVESTIGATIONS ----- [build.log] ... ccache gcc -c -I. -I../../../../../../src/gallium/include -I../../../../../../src/gallium/auxiliary -I../../../../../../src/gallium/drivers -I../../../../../../src/gallium/drivers/r300 -I/usr/include/drm -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS radeon_r300.c -o radeon_r300.o radeon_drm_buffer.c: In function 'radeon_drm_bufmgr_set_tiling': radeon_drm_buffer.c:319: error: 'RADEON_BO_FLAGS_MICRO_TILE_SQUARE' undeclared (first use in this function) radeon_drm_buffer.c:319: error: (Each undeclared identifier is reported only once radeon_drm_buffer.c:319: error: for each function it appears in.) make[5]: *** [radeon_drm_buffer.o] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: Leaving directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon/core' make[4]: *** [default] Error 1 make[4]: Leaving directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/sd/src/mesa/mesa/src/gallium/winsys' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/sd/src/mesa/mesa/src' make: *** [default] Error 1 [/build.log] ----- EOT ----- |
|
From: Francisco J. <cur...@ri...> - 2010-03-23 11:01:04
|
Ian Romanick <id...@fr...> writes: > Kristian Høgsberg wrote: >> 2010/3/22 Ian Romanick <id...@fr...>: >>> Kristian Høgsberg wrote: >>>> 2010/2/8 Francisco Jerez <cur...@ri...>: >>>>> The spec says (regarding glXCreateWindow): "If there is already a >>>>> GLXFBConfig associated with win (as a result of a previous >>>>> glXCreateWindow call), then a BadAlloc error is generated.". It will >>>>> also come useful to implement DRI2InvalidateBuffers for the indirect >>>>> case. >>>>> >>>>> Signed-off-by: Francisco Jerez <cur...@ri...> >>> I've put this version of this patch (with krh's R-b) in my GLX-fixes >>> tree. Are the all the rest in Kristian's dri2-invalidate tree? >> >> We dropped this one, and the rest is in my dri2-invalidate tree. > > Why was it dropped? I believe that it enforced correct behavior. If > this really does need to be removed, any suggestions how to fix my tree? > :( git-revert seems the only way, but that makes for ugly history in a > tree like this. We stopped caring about this one because a refactoring of the dri2 code made it irrelevant to the invalidate event implementation, but yeah, I think the behavior it enforced was correct. |
|
From: Pauli N. <su...@gm...> - 2010-03-23 09:29:14
|
2010/3/23 Ian Romanick <id...@fr...>: > Kristian Høgsberg wrote: >> 2010/3/22 Ian Romanick <id...@fr...>: >>> Kristian Høgsberg wrote: >>>> 2010/2/8 Francisco Jerez <cur...@ri...>: >>>>> The spec says (regarding glXCreateWindow): "If there is already a >>>>> GLXFBConfig associated with win (as a result of a previous >>>>> glXCreateWindow call), then a BadAlloc error is generated.". It will >>>>> also come useful to implement DRI2InvalidateBuffers for the indirect >>>>> case. >>>>> >>>>> Signed-off-by: Francisco Jerez <cur...@ri...> >>> I've put this version of this patch (with krh's R-b) in my GLX-fixes >>> tree. Are the all the rest in Kristian's dri2-invalidate tree? >> >> We dropped this one, and the rest is in my dri2-invalidate tree. > > Why was it dropped? I believe that it enforced correct behavior. If > this really does need to be removed, any suggestions how to fix my tree? > :( git-revert seems the only way, but that makes for ugly history in a > tree like this. You can fix git history with git commit --amend and git rebase --onto. If your tree mixes good and bad commit it would be easier to create new branch and use git cherry-pick. |
|
From: Dave A. <ai...@gm...> - 2010-03-23 09:07:55
|
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca <jfo...@vm...> wrote:
> Dave,
>
> I don't oppose this new method -- it shouldn't be necessary to add fencing just to use pb_cache --, but this method adds a new way of doing the same thing.
>
> Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what about doing:
>
> boolean
> pb_cache_is_buffer_compat()
> {
> void map;
>
> map = pb_map(buf->buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER);
> if (map) {
> /* TODO: cache the map value for the first map */
> pb_unmap(buf->buffer);
> return TRUE;
> }
>
> return FALSE;
> }
Hi Jose
I've used your scheme but I'm not sure 100% of its correctness since
we might expect
different behaviour from maps that are referenced in flushed command
streams and maps
referenced in the current command stream. I've pushed the r300g bits
that do it correctly and
we haven't seen any regressions.
So my next bit is to bail out after is_busy check to avoid kernel
overheads for checking all
the buffers, but I'm a bit worried it might change behaviour of the
fenced/cached use case,
so I'd appreciate a bit of a review of it.
If this isn't possible I'm tempted to create pb_bufmgr_busy_cached and
do it all there,
I think nouveau could use something similiar.
Dave.
|
|
From: <bug...@fr...> - 2010-03-23 07:39:05
|
http://bugs.freedesktop.org/show_bug.cgi?id=27254 --- Comment #4 from Chia-I Wu <ol...@gm...> 2010-03-23 00:38:57 PST --- I think I should brought this up since 7.8 is about to be released. In gl_API.xml, we have <function name="HistogramEXT" alias="Histogram" static_dispatch="false"> C and X86-64 dispatcher correctly hide glHistogramEXT. However, up until recently, X86 dispatcher exposed the function. I've made a commit 41a87a43e11c664935349f938022d58d3e22da4e to honor gl_API.xml and hide the symbol (and some others). Does this sound fine to your or is this considered an ABI breakage? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Stephane M. <ste...@gm...> - 2010-03-23 07:18:10
|
On Tue, Mar 23, 2010 at 00:13, Corbin Simpson <mos...@gm...> wrote: > On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard <tst...@gm...> wrote: >> On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote: >>> >>> Nifty. Well, there's a few places to look for information. >>> >>> If you're not sure how the actual video card works, >>> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a >>> great starting point. Of particular interest is the 3D engine; r300g >>> only talks to the 3D part of the video card. >>> >>> The reference Gallium driver is probably identity, although softpipe >>> is a good reference as well. We also have documentation for the >>> Gallium API and associated bits; if you don't want to build it >>> yourself from the Mesa tree, there should be an up-to-date copy at >>> http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a >>> problem with the documentation, lemme know!) >>> >> >> Thanks for the information. >> >> After spending some time learning about the Gallium driver architecture, I >> think it might be better to set a goal to implement or improve a specific >> feature of the Gallium R300 driver rather than trying to get a specific >> game or application to work. Is there a feature that is currently missing >> from the R300 driver that might make a good project for the summer? > > Good question. There's a handful of things. Passing piglit might be a > good goal. Bumping the GL version further up, or solidifying the GLSL > support, might be good too. > Keep in mind you have to make SoC projects self-contained and doable in 3 months by a newcomer. So you have to measure the difficulty beforehand so you don't hand out trivial/impossible projects. Usually that requires a developer looking at the source and figuring out the amount of work required... Stephane |
|
From: Corbin S. <mos...@gm...> - 2010-03-23 07:16:33
|
On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson <mos...@gm...> wrote: > Good question. There's a handful of things. Passing piglit might be a > good goal. Bumping the GL version further up, or solidifying the GLSL > support, might be good too. Oh, and how could I forget this? We have a sizeable todo list: http://dri.freedesktop.org/wiki/R300ToDo ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <Mos...@gm...> |
102 messages has been excluded from this view by a project administrator.
