You can subscribe to this list here.
2001 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(34) |
Aug
(59) |
Sep
(16) |
Oct
(11) |
Nov
(83) |
Dec
(52) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(40) |
Feb
(82) |
Mar
(190) |
Apr
(72) |
May
(95) |
Jun
(128) |
Jul
(195) |
Aug
(267) |
Sep
(202) |
Oct
(88) |
Nov
(60) |
Dec
(34) |
2003 |
Jan
(81) |
Feb
(73) |
Mar
(74) |
Apr
(53) |
May
(15) |
Jun
(61) |
Jul
(32) |
Aug
(73) |
Sep
(121) |
Oct
(43) |
Nov
(27) |
Dec
(47) |
2004 |
Jan
(46) |
Feb
(90) |
Mar
(97) |
Apr
(87) |
May
(71) |
Jun
(103) |
Jul
(61) |
Aug
(15) |
Sep
(49) |
Oct
(32) |
Nov
(26) |
Dec
(4) |
2005 |
Jan
(33) |
Feb
(15) |
Mar
(27) |
Apr
(21) |
May
(29) |
Jun
(20) |
Jul
(16) |
Aug
(10) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2006 |
Jan
(2) |
Feb
(9) |
Mar
(2) |
Apr
(7) |
May
(20) |
Jun
|
Jul
|
Aug
(13) |
Sep
(20) |
Oct
(11) |
Nov
(10) |
Dec
(7) |
2007 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
2008 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brian P. <bri...@tu...> - 2006-09-08 20:08:03
|
James Supancic wrote: >> The tilesort SPU broadcasts VBO drawing commands to all crservers. >> The tilesort SPU's state tracker keeps a client-side copy of the VBO >> data but does not analyze VBO drawing commands to compute the bounding >> box (which would be used for bucketing). >> >> The cost of computing the bounding boxes in these cases could be more >> than just broadcasting the command. >> >> If you want to optimize things, you'll have to add new >> glDrawArrays/glDrawElements code to the tilesort SPU that computes >> bounding boxes. >> >> Unfortunately, you can't just look at a VBO to determine bounds since >> there's no way to interpret the VBO's data; you need the glVertexArray >> parameters, etc. which can vary from one draw to the next. > > > I am not talking about anything that advanced. Most of the time the > rendering window will not be on both of the ATI monitors. Methinks a > simple way to filter out unneeded glDraw* commands is to check: > (thread->currentContext->currentWindow->server+index)->num_extents > If the server does not have any extents, than it isn't really doing > much? We should be able to drop a lot of commands? > > I tried checking this in a for loop, and using > crPackSetBuffer(thread->packer,&(thread->buffer[index])); > when it did not equal zero and I set it back to what it was before > after the loop ended. > > I think I am now putting the unrolled draw elements call into the > server specific buffers? > Performance has gone up a lot, but there are some strange visual > errors. It looks as if some coordinate data is being truncated? > > > Obviously, putting the data into the server specific buffer doesn't > have the same effect as putting it into the global buffer. What is the > correct way to send a command to a single server? > > I think the thread->buffer buffers are for the exclusive use of the > state tracker? > > Should I try to find a way to use the state tracker for sending the > data to the servers as needed? Or maybe add new buffers and add code > to the flush mechanism for this purpose? I think the best place to plug in this features is right after the bucketing stage. The bucketing stage looks at bounding boxes to determine which geometry buffers go to each crserver. The tilesortspuBucketGeometry() function produces a bitmask indicating which crservers need the geometry. You'll need to add something like this: for (i = 0; i < num servers; i++) if (server[i].extents are null) bucketInfo->hits[i / 32] &= ~(1 << (i % 32)); -Brian |
From: James S. <arr...@gm...> - 2006-09-08 05:07:44
|
> The tilesort SPU broadcasts VBO drawing commands to all crservers. > The tilesort SPU's state tracker keeps a client-side copy of the VBO > data but does not analyze VBO drawing commands to compute the bounding > box (which would be used for bucketing). > > The cost of computing the bounding boxes in these cases could be more > than just broadcasting the command. > > If you want to optimize things, you'll have to add new > glDrawArrays/glDrawElements code to the tilesort SPU that computes > bounding boxes. > > Unfortunately, you can't just look at a VBO to determine bounds since > there's no way to interpret the VBO's data; you need the glVertexArray > parameters, etc. which can vary from one draw to the next. I am not talking about anything that advanced. Most of the time the rendering window will not be on both of the ATI monitors. Methinks a simple way to filter out unneeded glDraw* commands is to check: (thread->currentContext->currentWindow->server+index)->num_extents If the server does not have any extents, than it isn't really doing much? We should be able to drop a lot of commands? I tried checking this in a for loop, and using crPackSetBuffer(thread->packer,&(thread->buffer[index])); when it did not equal zero and I set it back to what it was before after the loop ended. I think I am now putting the unrolled draw elements call into the server specific buffers? Performance has gone up a lot, but there are some strange visual errors. It looks as if some coordinate data is being truncated? Obviously, putting the data into the server specific buffer doesn't have the same effect as putting it into the global buffer. What is the correct way to send a command to a single server? I think the thread->buffer buffers are for the exclusive use of the state tracker? Should I try to find a way to use the state tracker for sending the data to the servers as needed? Or maybe add new buffers and add code to the flush mechanism for this purpose? Thank you for your time, James Steven Supancic III |
From: Brian P. <bri...@tu...> - 2006-09-05 18:14:29
|
James Supancic wrote: > I have a dual head ATI system (One GPU, two Render SPUs), which > performs very poorly. After much profiling I have determined that it > is spending a lot of time (near 99.4%) in fglrx.so. I find that the > functions in this library are mostly invoked by functions related to > the processing of unrolled glDrawElemnts commands (glArrayElement > calls are causing this CPU usage). I wrote a simple test application. > My results show poor performance by the ATI GPU when two concurrent > processes use VBOs and glArrayElement to draw objects. > > As I only need to be rendering to one of the ATI heads at a time, I > think a possible solution is to filter out unneeded glDrawElements > commands. > > This could be done by checking the rendering window rectangle against > the rectangle of each monitor. If the rectangles intersect, we would > set the Pack Buffer to thread->buffer[current_server] and then do what > we normally do to translate and pack the command for that server. > Repeat for each server. When done, set the Pack buffer back to > thread->geometry_buffer (This is what it was before, right)? This > would prevent the glDrawElement command from effecting servers that do > not have the GL rendering window on them. The tilesort SPU broadcasts VBO drawing commands to all crservers. The tilesort SPU's state tracker keeps a client-side copy of the VBO data but does not analyze VBO drawing commands to compute the bounding box (which would be used for bucketing). The cost of computing the bounding boxes in these cases could be more than just broadcasting the command. If you want to optimize things, you'll have to add new glDrawArrays/glDrawElements code to the tilesort SPU that computes bounding boxes. Unfortunately, you can't just look at a VBO to determine bounds since there's no way to interpret the VBO's data; you need the glVertexArray parameters, etc. which can vary from one draw to the next. > Is dropping glDrawElements commands for render SPUs who's monitors > don't intersect the OpenGL output window acceptable practice? Will it > cause problems for downstream SPUs? > > What is the best method to integrate such optimizations into Chromium? > > I am only aware of 2 types of pack buffers in the tilesort spu, the > geometry_buffer, and the server specific buffers. Are there any others > I should know about? Is your application putting its array indices into a GL_ELEMENT_ARRAY_BUFFER VBO? To get best performance, you want both your vertex data and indices to be in VBOs. -Brian |
From: James S. <arr...@gm...> - 2006-09-04 22:05:32
|
I have a dual head ATI system (One GPU, two Render SPUs), which performs very poorly. After much profiling I have determined that it is spending a lot of time (near 99.4%) in fglrx.so. I find that the functions in this library are mostly invoked by functions related to the processing of unrolled glDrawElemnts commands (glArrayElement calls are causing this CPU usage). I wrote a simple test application. My results show poor performance by the ATI GPU when two concurrent processes use VBOs and glArrayElement to draw objects. As I only need to be rendering to one of the ATI heads at a time, I think a possible solution is to filter out unneeded glDrawElements commands. This could be done by checking the rendering window rectangle against the rectangle of each monitor. If the rectangles intersect, we would set the Pack Buffer to thread->buffer[current_server] and then do what we normally do to translate and pack the command for that server. Repeat for each server. When done, set the Pack buffer back to thread->geometry_buffer (This is what it was before, right)? This would prevent the glDrawElement command from effecting servers that do not have the GL rendering window on them. Is dropping glDrawElements commands for render SPUs who's monitors don't intersect the OpenGL output window acceptable practice? Will it cause problems for downstream SPUs? What is the best method to integrate such optimizations into Chromium? I am only aware of 2 types of pack buffers in the tilesort spu, the geometry_buffer, and the server specific buffers. Are there any others I should know about? Thank you for your time, James Steven Supancic III |
From: <dr...@bf...> - 2006-09-02 12:16:07
|
Brian Paul wrote: >> Maybe a better solution might be to include the >> PFD_GENERIC_ACCELERATED flag instead? According to [2] this flag >> indicates sort of a hybrid driver which might better suit Chromium. > > I was planning on releasing Cr 1.9 today. I'd rather not risk a > last-minute change, OK? No problem. I think the semantics of these flags are not very clear. Moreover I think they are not properly used by the BS Contact VRML/X3D application either. That is, if neither PFD_GENERIC_FORMAT nor PFD_GENERIC_ACCELERATED is set (as it is the case with Chromium) the application should not take this as a reason to abort. I will try to discuss this matter with the folks at Bitmanagement. Michael |
From: Brian P. <bri...@tu...> - 2006-09-01 18:19:52
|
Chromium 1.9 can be downloaded from SourceForge: http://sourceforge.net/project/showfiles.php?group_id=16529 Thanks to everyone that helped with release candidate testing, etc. -Brian |
From: Brian P. <bri...@tu...> - 2006-09-01 18:03:30
|
Michael D=FCrig wrote: > Brian Paul wrote: >=20 >>Michael D=FCrig wrote: >> >>>2. In wglChoosePixelFormat() okayFlags should include=20 >>>PFD_GENERIC_FORMAT. The flag basically says that there is no hardware=20 >>>acceleration at all [1], [2]. >> >>I'm a little hesitant to make the second change. Is there a chance any= =20 >>apps will check for that flag and decide they don't want to run? >> >>Chromium isn't a hardware driver and not a full software driver either. >> >=20 >=20 > I had to set this flag in order to get the BS Contact VRML/X3D software= =20 > to work (see http://bitmanagement.de/products/bs_contact_vrml.en.html).= =20 > This software can either run in 'normal mode' or in 'software rendering= '=20 > mode. In normal mode it checks for the flag PFD_GENERIC_ACCELERATED and= =20 > in software rendering mode it checks for the PFD_GENERIC_FORMAT flag.=20 > Without my patch the software wont run with Chromium. >=20 > Maybe a better solution might be to include the PFD_GENERIC_ACCELERATED= =20 > flag instead? According to [2] this flag indicates sort of a hybrid=20 > driver which might better suit Chromium. I was planning on releasing Cr 1.9 today. I'd rather not risk a=20 last-minute change, OK? -Brian |
From: <dr...@bf...> - 2006-09-01 16:08:47
|
Brian Paul wrote: > Michael Dürig wrote: >> >> 2. In wglChoosePixelFormat() okayFlags should include >> PFD_GENERIC_FORMAT. The flag basically says that there is no hardware >> acceleration at all [1], [2]. > > I'm a little hesitant to make the second change. Is there a chance any > apps will check for that flag and decide they don't want to run? > > Chromium isn't a hardware driver and not a full software driver either. > I had to set this flag in order to get the BS Contact VRML/X3D software to work (see http://bitmanagement.de/products/bs_contact_vrml.en.html). This software can either run in 'normal mode' or in 'software rendering' mode. In normal mode it checks for the flag PFD_GENERIC_ACCELERATED and in software rendering mode it checks for the PFD_GENERIC_FORMAT flag. Without my patch the software wont run with Chromium. Maybe a better solution might be to include the PFD_GENERIC_ACCELERATED flag instead? According to [2] this flag indicates sort of a hybrid driver which might better suit Chromium. Michael |
From: Brian P. <bri...@tu...> - 2006-09-01 13:20:44
|
Michael D=FCrig wrote: >=20 > Please find attached a patch with some fixes for the OpenGL stub on=20 > windows: >=20 > 1. The functions wglGetCurrentContext() and wglGetCurrentDC() return=20 > NULL in the current implementation. I changed them to return the proper= =20 > GL context and device context respectively. >=20 > 2. In wglChoosePixelFormat() okayFlags should include=20 > PFD_GENERIC_FORMAT. The flag basically says that there is no hardware=20 > acceleration at all [1], [2]. I'm a little hesitant to make the second change. Is there a chance=20 any apps will check for that flag and decide they don't want to run? Chromium isn't a hardware driver and not a full software driver either. -Brian |
From: <dr...@bf...> - 2006-09-01 00:35:15
|
Please find attached a patch with some fixes for the OpenGL stub on windows: 1. The functions wglGetCurrentContext() and wglGetCurrentDC() return NULL in the current implementation. I changed them to return the proper GL context and device context respectively. 2. In wglChoosePixelFormat() okayFlags should include PFD_GENERIC_FORMAT. The flag basically says that there is no hardware acceleration at all [1], [2]. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/ntopnglr_73jm.asp [2] http://www.microsoft.com/msj/archive/S2085.aspx Michael |
From: <dr...@bf...> - 2006-08-23 22:38:10
|
> OK, I tested the tilesortspu_misc.c change and it seems OK. I checked > in your change. Thanks! I will make the tracker SPU available as soon as it is more stable and general as it is in its current stage. This will most likely take some weeks still. Michael |
From: Brian P. <bri...@tu...> - 2006-08-23 22:06:43
|
Brian Paul wrote: > Michael D=FCrig wrote: >=20 >>I am currently working on a SPU which facilitates integration of=20 >>tracking devices with Chromium. For usage for example in a CAVE=20 >>environment. >> >>In order to do so I patched the Chromium code base in a few places. The= =20 >>patch is attached. Since I am not sure which parts of the patch are=20 >>desired and will finally make its way into Chromium I do not release my= =20 >>tracker SPU yet. I will wait until I see which parts get through and=20 >>will then try to adapt my SPU accordingly. >> >>Regarding the patch, there is only one part which is *really* required=20 >>in order to get head tracking working at all: In tilesortspu_misc.c=20 >>function tilesortspu_ChromiumParametervCR() the case=20 >>GL_SERVER_PROJECTION_MATRIX_CR needs to be handled similar to the case=20 >>GL_SERVER_VIEW_MATRIX_CR otherwise the servers will never see the new=20 >>projection matrix. >>The other parts add functionality which might be implemented elsewhere=20 >>but seemed to fit into Chromium for one reason or another. >=20 >=20 > I'm a little worried that your changes to tilesortspu_misc. will break=20 > the current per-server projection feature. I'll check in the rest=20 > then try to test the tilesort change when I find some time. OK, I tested the tilesortspu_misc.c change and it seems OK. I checked=20 in your change. -Brian |
From: Brian P. <bri...@tu...> - 2006-08-23 16:43:37
|
Michael D=FCrig wrote: >=20 > I am currently working on a SPU which facilitates integration of=20 > tracking devices with Chromium. For usage for example in a CAVE=20 > environment. >=20 > In order to do so I patched the Chromium code base in a few places. The= =20 > patch is attached. Since I am not sure which parts of the patch are=20 > desired and will finally make its way into Chromium I do not release my= =20 > tracker SPU yet. I will wait until I see which parts get through and=20 > will then try to adapt my SPU accordingly. >=20 > Regarding the patch, there is only one part which is *really* required=20 > in order to get head tracking working at all: In tilesortspu_misc.c=20 > function tilesortspu_ChromiumParametervCR() the case=20 > GL_SERVER_PROJECTION_MATRIX_CR needs to be handled similar to the case=20 > GL_SERVER_VIEW_MATRIX_CR otherwise the servers will never see the new=20 > projection matrix. > The other parts add functionality which might be implemented elsewhere=20 > but seemed to fit into Chromium for one reason or another. I'm a little worried that your changes to tilesortspu_misc. will break=20 the current per-server projection feature. I'll check in the rest=20 then try to test the tilesort change when I find some time. -Brian |
From: <dr...@bf...> - 2006-08-21 09:28:08
|
I am currently working on a SPU which facilitates integration of tracking devices with Chromium. For usage for example in a CAVE environment. In order to do so I patched the Chromium code base in a few places. The patch is attached. Since I am not sure which parts of the patch are desired and will finally make its way into Chromium I do not release my tracker SPU yet. I will wait until I see which parts get through and will then try to adapt my SPU accordingly. Regarding the patch, there is only one part which is *really* required in order to get head tracking working at all: In tilesortspu_misc.c function tilesortspu_ChromiumParametervCR() the case GL_SERVER_PROJECTION_MATRIX_CR needs to be handled similar to the case GL_SERVER_VIEW_MATRIX_CR otherwise the servers will never see the new projection matrix. The other parts add functionality which might be implemented elsewhere but seemed to fit into Chromium for one reason or another. Michael |
From: Brian P. <bri...@tu...> - 2006-08-18 22:50:14
|
Andres Lagar Cavilla wrote: > Hi Brian, > >> One easy thing to do is run 'top' on the crserver host while >> Chromium's running to see how busy the CPU is. > > > top with glxgears shows CPU at 99% (not too surprising). top with quake > 3 shows CPU steadily around 30-40%. My card is an ATI X600, not the > fastest, not the slowest. > >> Do you have a certain configuration in mind? > > > I was thinking about the simplest configuration: pack SPU on one side, > render SPU on the other side. Potentially feedback and array SPUs on the > client side, depending on the applications need. Regarding to my > previous post on dlm, is expando a potentially useful SPU, or is there > for the sake of debugging? It's mostly for debugging. I think Bob said so in his message a few days ago. One thing I've toyed with is an option to remove the state tracker from the crserver. It's really only needed when the crserver is accepting streams from multiple clients. That could save some CPU time. -Brian |
From: Andres L. C. <and...@cs...> - 2006-08-18 20:47:20
|
Hi Brian, > One easy thing to do is run 'top' on the crserver host while > Chromium's running to see how busy the CPU is. top with glxgears shows CPU at 99% (not too surprising). top with quake 3 shows CPU steadily around 30-40%. My card is an ATI X600, not the fastest, not the slowest. > Do you have a certain configuration in mind? I was thinking about the simplest configuration: pack SPU on one side, render SPU on the other side. Potentially feedback and array SPUs on the client side, depending on the applications need. Regarding to my previous post on dlm, is expando a potentially useful SPU, or is there for the sake of debugging? Thanks for the other info Andres |
From: Brian P. <bri...@tu...> - 2006-08-18 20:32:28
|
Andres Lagar Cavilla wrote: > Hi again, > I've been reviewing an old thread regarding chromium performance and was > wondering what is the state of matters as of today, v1.9-rc4 > Assuming the network is not the limiting factor (big chunk of an > assumption, heh): > - Is chromium limited by CPU consumption during unpacking? I've seen > high rates of CPU occupation by crserver for several apps (quake 3, > mplayer, glxgears) It depends. If the graphics card is very fast, the limiting factor may be the unpacker/crserver, or it may be the network. One easy thing to do is run 'top' on the crserver host while Chromium's running to see how busy the CPU is. > - What about all the pointer swinging as function calls go down the > SPU's? If someone wanted to optimize a particular set-up, would it be > worthwhile replacing the spu loading mechanism with something less > general but potentially faster? I don't think function calls are too big of deal there; we're doing just about as good as we can. On Linux (and other platforms) we're using assembly code for dispatching GL functions (see opengl_stub/Linux_i386_exports.s). And if a SPU doesn't implement/override a particular GL function there's no undue cost. > - Anything else? With all the different possible Chromium configs, it's hard to be specific. Do you have a certain configuration in mind? -Brian |
From: James S. <arr...@gm...> - 2006-08-16 06:04:18
|
I want to use gprof to get a overview of how the CPU consumption is distributed in my setup. I added CFLAGS+=-pg CXXFLAGS+=-pg LDFLAGS+=-lc_p to the Makefile right after "include $(TOP)arch.mk", and then make clean && make. Everything ran fine, but I got no gmon.out file. I also added to the begining of options.mk CFLAGS+=-pg CXXFLAGS+=-pg and got nothing as well. What is the best way to profile Chromium for CPU usage? Will gprof work? How? Thank you for your time, James Steven Supancic III |
From: Robert E. <pa...@tu...> - 2006-08-15 17:30:27
|
> I'm trying to understand what is the functionality of the dlm module in > Chromium. "DLM" is the Display List Manager. It provides for display list state roughly similar capabilities to what the state tracker provides for simple state, and can be used for similar purposes. It is typically used to record the contents of all display lists in memory, for replay when necessary or for debugging issues involving display list contents. It can also be used to track state changes due to display list use (i.e., glCallList() can cause graphics state changes that are difficult to track any other way). > Scanning the cr tree I found there are rather limited uses of it, > actually three SPUs: replicate, tilesort and expando > > The first two fan-out one gl stream to several renderers, so I infer > that dlm is used to keep track of the display lists in these one-to-many > environments. Right. "tilesort" has options that allow it to send display lists "lazily", i.e. only to those hosts that need it. In this case the display lists are cached on the host, and replayed as necessary. "tilesort" also has an option to enable display list state tracking, which fixes some applications that rely on the use of state changes in display lists. "replicate" is used for a specialized type of state replication for a particular VNC implementation. This implementation uses an encoder module working beside the normal VNC stream in which the OpenGL command stream is encoded; the commands are then rendered on the remote viewer (instead of having the commands rendered locally and transmitted as pixmaps; this is a performance improvement for some applications). The problem is that a new VNC viewer can attach at any time; and any new VNC viewer needs the entire OpenGL state (including display lists) sent to it so it can "pick up" already-started instances of OpenGL programs. That's what the DLM is doing there. > What about expando? The description indicates it "unfolds" a display > list. This will impact performance...in which scenario is this SPU > useful? debugging? does it have to do with correctness/conformance? "expando" is something of a "toy" SPU, sort of like the "wet" SPU. It provides an example implementation of how an SPU might use a particular feature, in a nominally valid but not terribly useful sort of way. (It's certainly the case that the "wet" SPU is more fun than the "expando" SPU, though. :-) Bob Ellison Tungsten Graphics, Inc. |
From: James S. <arr...@gm...> - 2006-08-15 16:42:56
|
My understanding is that a display list is basically a sequence of OpenGL commands that are sent to their server and from that point onward may be invoked by a single command. In this way, we avoid having to send the whole sequence to the server every time we use it (it saves bandwidth). The replicate has something to do with the VNC SPU, which I am not familiar with yet. The tilesort SPU performs a number of "optimizations" using display lists. For example, I think it can compute which tiles the DL (Display List) effects and send it to only the Render SPUs that are on that tile (in theory, with the right configuration). For example the option "auto_dlist_bbox" tells the tilesort SPU to compute a bounding box for the dlist and only send CallList commands to tiles that will be effected by that dlist. The "lazy_send_dlists" sends DLs only to the tiles that need them, and only when they need them. ig. if a DL is only needed on one tile, it is only sent to that tile. If it later is needed on another tile it is then sent to the second tile. It optimizes performance. In general, the Expando SPU would hurt performance, but there is a lot of things to account for (in a few rare cases it might make things faster?). My guess is that it is for debugging. Thank you for your time, James Steven Supancic III |
From: Andres L. C. <and...@cs...> - 2006-08-15 16:16:50
|
Hi again, I've been reviewing an old thread regarding chromium performance and was wondering what is the state of matters as of today, v1.9-rc4 Assuming the network is not the limiting factor (big chunk of an assumption, heh): - Is chromium limited by CPU consumption during unpacking? I've seen high rates of CPU occupation by crserver for several apps (quake 3, mplayer, glxgears) - What about all the pointer swinging as function calls go down the SPU's? If someone wanted to optimize a particular set-up, would it be worthwhile replacing the spu loading mechanism with something less general but potentially faster? - Anything else? Thanks for any insights Andres |
From: Andres L. C. <and...@cs...> - 2006-08-15 15:50:43
|
Hi, I'm trying to understand what is the functionality of the dlm module in Chromium. Scanning the cr tree I found there are rather limited uses of it, actually three SPUs: replicate, tilesort and expando The first two fan-out one gl stream to several renderers, so I infer that dlm is used to keep track of the display lists in these one-to-many environments. What about expando? The description indicates it "unfolds" a display list. This will impact performance...in which scenario is this SPU useful? debugging? does it have to do with correctness/conformance? Thanks a lot to anyone who can shed some light on this :) Andres |
From: Brian P. <bri...@tu...> - 2006-08-10 16:19:24
|
I've made another set of Chromium 1.9 release candidate archives: http://chromium.sourceforge.net/beta/ This has a number of bug fixes from the past couple months. I'd like to wrap up 1.9 soon so please test and report any problems. -Brian |
From: Brian P. <bri...@tu...> - 2006-05-29 14:34:08
|
I've put a third release candidate of Chromium 1.9 at http://chromium.sourceforge.net/beta/ This includes a number of compilation fixes, notably, disabling -Werror for the release/optimized build. -Brian |
From: Eric S. <er...@sa...> - 2006-05-24 22:55:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 24 May 2006, Brian Paul wrote: > Eric Sandall wrote: <snip> >> After applying all patches for initialization posted so far and even >> with removing '-Werror' from configs/Linux.mk, I get this error >> (though it did not show up earlier when I successfully built cr 1.9rc2 >> earlier): >> Compiling tsfuncs.c >> tsfuncs.c: In function =91ts_CreateContext=92: >> tsfuncs.c:554: error: too few arguments to function >> =91tab->CreateContext=92 >> tsfuncs.c: At top level: >> tsfuncs.c:3726: warning: initialization from incompatible pointer type >> tsfuncs.c: In function =91ts_CreateContext=92: >> tsfuncs.c:555: warning: control reaches end of non-void function >> gmake[2]: *** [../built/crfaker/Linux/tsfuncs.o] Error 1 >> gmake[1]: *** [dep] Error 2 >> make: *** [opengl_stub.subdir] Error 2 >> >> gcc 4.1.0-3 on Fedora Core 5. I've tried a 'clean' cr-1.9rc2 build >> with only removing '-Werror' from CXXFLAGS and CFLAGS in >> configs/Linux.mk and still receive the above. >> >> I found the difference. If I set "THREADSAFE=3D1" in options.mk I get >> the above error, but if I leave "THREADSAFE=3D0" in options.mk >> cr-1.9rc2 compiles fine. > > Try removing the opengl_stub/tsfuncs.c file. It should get regenerated b= y > the tsfuncs.py script. It looks like the .c file was accidentally includ= ed > in the tarball. Removing opengl_stub/tsfuncs.c allowed cr-1.9rc2 to build with THREADSAFE=3D1, thanks. :) - -sandalle - -- Eric Sandall | Source Mage GNU/Linux Developer er...@sa... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEdORuHXt9dKjv3WERArnAAJ9NnzfVzYTYf901UFAXdwhDF9on7wCgtUIp RfysdRN0WpGzHQrpmul60/M=3D =3DAvNb -----END PGP SIGNATURE----- |