zaar69 Posted July 20, 2007 Report Share Posted July 20, 2007 (edited) Hola! Estoy viendo en esta pagina (http://www.flightsimworld.com/forums/index.php?showtopic=115345&st=0) que se puede mejorar el rendimiento de FSX SP1 variando la config, pero la verdad es que estoy muy pez en ingles y me pierdo mucho. Alguien sabe si esto funciona? Gracias! Edited July 20, 2007 by zaar69 Quote Link to comment Share on other sites More sharing options...
kgusto Posted July 20, 2007 Report Share Posted July 20, 2007 Yo tampoco ando muy ducho d inglés, así q me sumo a la petición de q un alma caritativa traduzca tan preciado texto... Quote Link to comment Share on other sites More sharing options...
TzT Posted July 21, 2007 Report Share Posted July 21, 2007 (edited) TRADUCCIÓN COMPLETADA!! I just thought I'd fire these over here from Phil's blog. There is a tweak to control scheduling of threads on cores. It is not recommended to change these settings unless you have a performance reduction and/or maxed out CPU loads in the PerfMonitor. The tweak is Edit:Fixed a typo here [JOBSCHEDULER] AffinityMask=n where n num of cores scheduled 1 = 1 core 0001 3 = 2 cores 0011 7 = 3 cores 0111 15= 4 cores 1111 Este es un apaño pora el control de programación de tareas en los núcleosNo es recomendable cambiar estos ajustes a menos que tengas una reducción de rendimiento y/o cargas de CPU maximizadas (¿?) en el PerfMonitor. El truco es: Edito: corregida una errata aquí [JOBSCHEDULER] AffinityMask=n donde n numero de núcleos programados 1 = 1 core 0001 3 = 2 cores 0011 7 = 3 cores 0111 15= 4 cores 1111 ---- There is additional code to reduce blurries. If you get random texture tiles that appear in a solid color this may help. In some cases, the textures generated from this code can get throttled and will be timed out. The time out config value is [TERRAIN] SWAP_WAIT_TIMEOUT=<number_of_frames> The default is 30 frames. Otro código más para reducir los blurries. Si tomas azulejos (cada porción de terreno, los famosos cuadraditos que vemos en altura) de textura aleatorios que aparecen en un color sólido quizás esto ayude.En algunos casos, las texturas generadas por este código pueden estar aceleradas y ser timed out (¿descartadas?). El valor de configuración de time out es: [TERRAIN] SWAP_WAIT_TIMEOUT=<numero_de_frames> Por defecto 30 frames. -- There are new config items to control VSYNC for fullscreen and windowed separately [DISPLAY] ForceFullScreenVSync, default is TRUE ForceVSync, default is FALSE We have seen cases where when VSYNC is on in fullscreen causing major fluctuations in frame rate especially when setting the rate limiter above 45. If you run into widely fluctuating FPS in fullscreen when aiming for above 45, try turning VSYNC off or reducing below 40. Hay nuevos puntos de configuración para controlar el VSYNC (¿Sincronización de V(algo)?) independientemente para pantalla completa o maximizado [DISPLAY] ForceFullScreenVSync, default is TRUE ForceVSync, default is FALSE Hemos visto casos en los que cuando VSYNC está activado en pantalla completa causando graves fluctuaciones en los frames por segundo, especialmente cuando el ajuste de limitación de frames es superior a 45. Si te rula normalmente con fluctuacioens de FPS en pantalla completa cuando tiene máximo por encima de 45, prueba desconectando VSYNC o reducir los FPS por debajo de 40. -- For the dusk/dawn textures some people feel, subjectively, the result is too dark or too light. There are 2 items that allow the transition time to be changed: [GRAPHICS] DAY_THRESHOLD NIGHT_THRESHOLD acceptible values are 0 to 65535. Defaults: DAY: 32768 NIGHT: 4096 These represent the amount of 'ambient' light at the ends of the day/night blend threshold. Zero is perfect dark, 65535 is full day sun at noon in the summer. Para las texturas de amanecer/atardecer, a alguna gente le parece, subjetivamente, que el resultado es demasiado oscuro o demasiado claro. Tenemos dos cosas que permiten cambiar el intervalo de transición [GRAPHICS] DAY_THRESHOLD NIGHT_THRESHOLD el rango de valores está entre 0 y 65535. Por defecto: DAY: 32768 NIGHT: 4096 -- There is a tweak that helps with panel updates, especially the glass panel. If you use the glass panel and notice very slow updates. There is a 2 part tweak: [GRAPHICS] DirtyRegionUpdateLimit=<integer> By default this UINT32_MAX (i.e. four billion or so) so it has no effect. Setting it to zero effectively forces full texture updates instead. Setting it to smaller numbers (1-1000) might improve performance if the card is slow at full texture updates and does not have a high overhead for incremental updates. [GRAPHICS] MergeDirtyRegionUpdates=<0/1> By default this is 0 (i.e. disabled) so it has no effect. Setting it to 1 (enabled) causes us to merge all of the dirty rects into a single large dirty rect. This means that we will only do a single partial texture update. This may work well if the card is slow at full texture updates and does have high overhead for incremental updates. Este es un truco que ahuda con los refrescos del panel, especialmente en los paneles de cristal. Si usas paneles acristalados y notas un refresco muy lento (prueba a modificar estos parámetros). Este es un truqui en 2 partes: [GRAPHICS] DirtyRegionUpdateLimit=<integer*> (*enteros, sus negativos y el cero) Por defecto este UINT32_MAX (por ejemplo cuatro mil millones o más) no tiene ningún efecto. En cambio, poniéndolo a 0, fuerza un refresco completo de texturas más efectivo. Valores más pequeños (1-1000) podría mejorar el rendimiento si la tarjeta (de vídeo) va lenta con refresco completo, y no tiene una gran capacidad para refrescos incrementales (¿?) [GRAPHICS] MergeDirtyRegionUpdates=<0/1> Por defecto está en 0 (desconectado) por lo que no tiene ningún efecto Cambiándolo a 1 (conectado) nos causa una fusión de todos las rects (¿?) sucias en una sola y gran rect (¿?) sucia. ( ) Esto significa que solo haremos un refresco parcial de una textura. Podría funcionar bien si la tarjeta va lenta con refresco completo de texturas y tiene una alta capacidad para refrescos incrementales (¿?) --- There is a scenery tweak to eliminate very small objects, which can reduce render time. [sCENERY] SmallPartRejectRadius=<pixels> Basically this culls out small model parts (e.g. air conditioners on roofs of buildings, aircraft doors) if their radius would occupy less than the specified number of screen pixels. The default is 1.0 (i.e. 1 pixel). 2, and 4 are the next 2 settings we advise. Can significantly improve performance but may cause "popping" of small objects Acouple of other things to note, which hve been mentioned but worth bringing them together. Texture_bandwidth= Setting a higher value pre SP1 did help with blurries, this can now have a detremental effect using SP1. Mango and I managed to get find a nice happy medium by setting the value to 40. This helps eliminating stutters. FIBER_FRAME_TIME_FRACTION= This has a smaller effect on ground texture loading now as these processes have been moved onto the second core. Again lifted from PT's blog. So here is an idea. Occasionally I will publish information on various "tweaks" to the product and what they do. A "Tweak of the week" if you will. So let's start with the mysterious sounding FIBER_FRAME_TIME_FRACTION. There are page after page of google, I mean livesearch, hits on this term. Obviously people have been talking. That's probably due to the post Adam, our resident terrain guru, made here. Now we hope people don't hurt themselves with settings that deeply affect the engine like this, because there is always the possibility of misuse. Usually that is outweighed by the value of being informed, and the great thing about the community is sometimes interesting questions do crop up out of people using these settings. Este truqui de escenarios sirve para eliminar objetos demasiado pequeños, que pueden reducir el tiempo de renderizado. [sCENERY] SmallPartRejectRadius=<pixels> Básicamente esto selecciona partes pequeñas de los modelos (por ejemplo, aire acondicionado en los tejados de edificios, puertas de aviones) si su radio ocupa menos de los pixels especificados. El valor por defecto es 1.0 (por ejemplo 1 pixel). 2, y 4 son los dos siguiente parámetros que recomendamos. Pueden mejorar el rendimiento significativamente, pero podrían causar ¿saltos? de objetos pequeños. Un par de cosas más que señalar, que se han mencionado pero que merece la pena poner juntas. Texture_bandwidth= Ajustando un valor mayor antes del SP1 ayudó con los blurries, pero ahora puede ir en detrimento usando el SP1. Mango y yo probamos para encontrar un buen valor ajustandolo a 40. Esto ayuda eliminando los tartamudeos (¿saltos?) FIBER_FRAME_TIME_FRACTION= Este tiene un efecto menor sobre la carga de las texturas de tierra. Ahora esos procesos han sido movidos sobre el segundo core. De nuevo, fusilado desde el blog de PT. Ahí va una idea. Ocasionalmente publicaré información sobre varios trucos para el FS y lo que hacen. Un "Truco de la semana, si quereis llamarlo. Así que vamos a empezar con el misterioso sondeo FIBER_FRAME_TIME_FRACTION. Hay páginas y páginas en google, y quiero decir muchas, resultados sobre este término. Obviamente, la peña ha estado hablando sobre ello. Probablemente debido al post de Adam, nuestro residente gurú del terrenos, posteado aquí. Ahora esperamos que la gente no se haga daño (en los pc's) con los ajustes que afectan profundamente al motor (gráfico) como este, porque siempre existe la posibilidad de un uso incorrecto. Normalmente esto pesa más por el valor de ser informado y lo grande de la comunidad son las, a veces, interesantes cuestiones ¿que cultivan? (¿?) a la peña usando estos ajustes. Christian Buchner, author of TileProxy, recommended that Win64 users of TileProxy set FIBER_FRAME_TIME_FRACTION to 2.0 when the base value is .33. A lot of speculation about what that would be doing cropped up. Adam Szofran, our resident terrain guru, gave out the skinny for everyone. I posted it first on avsim.com, but wanted to repost it here so the information didn't get lost. Here are 2 quotes from Adam, verbatim: " FIBER_FRAME_TIME_FRACTION determines the maximum amount of time per frame that we will run fiber jobs on the primary thread. We measure how long it took to simulate and render and then multiply that time by FIBER_FRAME_TIME_FRACTION to determine how long to run the fibers. For example, if it took 10 milliseconds to simulate and render and FIBER_FRAME_TIME_FRACTION was set to the default value of 0.33, then we would allow the fibers on the primary thread to run for up to 10 * 0.33 = 3.3 milliseconds. For fraction values of 1.0 and 2.0, the time given to fibers would be 10 milliseconds and 20 milliseconds, respectively. The operation of FIBER_FRAME_TIME_FRACTION on single core machines has not changed since RTM. On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn't enough fiber work left to soak up the full time allowed by the default value of 0.33. Therefore, on multi-core machines, there's very little reason to tweak the fraction because it really only impacts performance of single core machines. " and " Please emphasize the pointlessness of tweaking this value on multi-core machines. Further, setting it to values greater than the default value on single-core machines can increase frame rate volatility because it increases the amount of time we *might* allocate to fibers if there is adequate work waiting in the queue. When the queue is full, we'll allocate the full amount of time to fibers but when the queue is empty, fibers get no time because there is no work to do. If the rate of new jobs entering the fiber queue is bursty and the full time allowed for fibers is large, then you can imagine how this would increase volatility. If people feel like the fibers aren't getting adequate resources, they would be better off leaving the fiber fraction alone and just lowering the frame rate limit slider, which helps divert more CPU time to primary thread fibers without increasing volatility. " I'd take those words as golden. He also wanted me to mention that TileProxy is using a FS9 path, basically because it is the only path available for the style of source data involved. However, that path requires massive amounts of file I/O and because of the huge number of files involved it completely blows the texture cache used by the terrain texture compositor. So there is a limit to how efficient that will ever be until we rework the architecture to be more accommodating. Another question was does photo-scenery benefit from the multi-core work, and Adams' answer was: " Photo scenery loading, like loading of all terrain data, benefits greatly from our multi-core work. The more cores the better. ------------------------------------------------------------------------------------- TERRAIN_MAX_AUTOGEN_TREES_PER_CELL= TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL= This is still valid with a maximum value of 6000 ------------------------------------------------------------------------------------- After looking round several forums it seems simmer are not taking note of one important thing regarding SP1. It's been mentioned so many times but here we go again. To guarantee the best results using SP1 Aces request that you install on a FRESH copy of FSX, or RTM as it's celled (This is your DVD version) Again information supplied from Phil's blog FSX SP1:Preparing to Install Setting up for SP1 SP1 needs a pristine RTM. That includes no add-ons. Many 3rd party add-ons can cause crashes, especially if they load dlls. In that case they will likely need to be refreshed. If you really don't want to do this, then perhaps you can consider running FSX from the command line using >fsx /ManualLoad This provides a dialog for every dll or xml exe that gets loaded so you track down who is the offender if there is an issue. However, most people don't know how to run FSX from the command line, thus it's safest to uninstall all add-ons. If you have performed any file modification tweaks, you will need to uninstall or repair RTM. Then install SP1. Then start installing your add-ons 1 by 1. Note: Uninstalling RTM deletes ALL content of - C:\Documents and Settings\All Users\Application Data\Microsoft\FSX C:\Documents and Settings\USERNAME\Application Data\Microsoft\FSX That is EVERY subfolder & file in that branch. If you don't back up and save, you will loose config files, flights, logbook, and rewards. Two files to consider saving: Logbook.bin & GrantedRewards.bin FSInsider.com will have an article live that discusses the uninstall scenario in more depth, please take the time to read it. ----------------------------------------------------------------------------------------------------- I'll keep adding things as tweaks become available but to be honest, I think SP! rock as it is lol !!!!!! Christian Buchner (como el filtro ), autor de TileProxy, recomienda que los usuarios que usen Win64 ajusten FIBER_FRAME_TIME_FRACTION a 2.0 cuando el valor base es .33. Salieron montones de especulaciones acerca de lo que ese ajuste estaría haciendo Adam Szofran, nuestro gurú de terrenos, soltó el flaco (¿dio los detalles?) para todos. Lo he posteado antes en avsim, pero he querido repostearlo aquí para que la información no se pierda. Aquí van dos citas de Adam, textualmente: "FIBER_FRAME_TIME_FRACTION determina el la máxima cantidad de tiempo por cada frame que correremos ¿trabajos de fibra? (debe ser algo de la gráfica que no sé traducir) sobre el primer hilo (referido a la fibra) Medimos cuánto tiempo tomó para simular y renderizar, entonces multiplica ese tiempo por FIBER_FRAME_TIME_FRACTION para determinar cuanto tiempo (empleará) para ejecutar las fibras. Por ejemplo, si tomó 10 ms para simular y renderizar, y FIBER_FRAME_TIME_FRACTION está ajustado al valor por defecto de 0.33, entonces permitiríamos a ejecutarse a las fribras del primer hilo hasta 10*.33=3.3 milisegundos. Para valores fraccion de 1.0 y 2.0, el tiempo dado a las fibras sería de 10 ms y 20 ms respectivamente. La operación de FIBER_FRAME_TIME_FRACTION sobre equipos de un sólo núcleo no han cambiado desde RTM (¿?). Por tanto, sobre máquinas multi-núcleo, hay una razón muy pequeña para modificar la fracción, porque realmente solo tiene impacto sobre el rendimiento de máquinas mono-núcleo." y "Por favor, enfatizar lo absurdo de modificar este parámetro en máquinas multi-core. Más allá, ajustándolo a valores mayores que por defecto en máquinas mono-core, puede incrementar la volatibilidad de los FPS porque incrementa la cantidad de tiempo que *podríamos* destinar a las fibras si hay el trabajo adecuado esperando en la cola. Cuando la cola está completa, destinaremos la cantidad total de tiempo a las fibras pero cuando la cola está vacía, las fibras no tendrán timepo porque no hay trabajo que hacer. Si la proporción de nuevos trabajos entrando en la cola de la fibra es brutal y el tiempo total permitido a las fibras es grande, entonces puedes imaginar como incrementará la volatibilidad. Si a la gente le parece que las fibras no están tomaando los recursos adecuados, podría ser mejor dejando solamente la fracción de fibra y bajar un poco el deslizador de FPS, que ayudará a desviar más tiempo de CPU a los fibras de hilo primario sin incrementar la volatibilidad." Guardo estas letras como oro en paño. Él también me pidió que mencionara que TileProxy está usando la ruta de FS9, básicamente porque es la única ruta disponible para el tipo de datos de origen involucrados. Sin embargo, esa ruta requiere grandes cantidades de Entradas/Salidas de archivos y debido a la enorme cantidad de archivos involucrados, revienta completamente la caché de texturas usadas por el compositor de texturas de terreno. Por lo que existe un límite para cuán eficiente será mientras re-trabajamos (¿?) la arquitectura para estar más cómodos. Otra pregunta fué ¿benefician los foto-escenarios desde el trabajo en multi-núcleo?, y la respuesta de Adam fue: "La carga de foto-escenarios, como la carga de todos los datos de terreno, se beneficia gratamente desde el trabajo en multi-núcleo. Cuantos más núcleos, mejor. -------------- TERRAIN_MAX_AUTOGEN_TREES_PER_CELL= TERRAIN_MAX_AUTOGEN_BUIDINGS_PER_CELL= Esto es todavía válido con un valor máximo de 6000. ------------- " (en el texto no lo especifica, pero creo que la cita acaba aquí) Después de mirar alrededor de varios foros, parece que los simuleros no toman nota respecto al SP1. Está siendo mencionado muchas veces pero aquí vamos de nuevo. Para garantizar los mejores resultados usando SP1, Aces requiere que instales sobre una copia FRESCA (instalación limpia) de FSX, o RTM (¿un modo de recuperación del sistema?), como esté celdado (¿? algún tipo de soporte o disposición de archivos?) (Esta es tu versión DVD) De nuevo, info suministrada del blog de Phil FSX SP1: Preparando para instalar. Ajustando para SP1 SP1 necesita un RTM original Esto no incluye añadidos. Algunos añadidos de terceras partes (comunidad libre?) pueden provocar cuelgues, especialmente si cargan dll's. En ese caso necesitarán ser refrescadas (¿reinstaladas?) Si realmente no quieres hacerlos, entonces tal vez puedas considerar ejecutar FSX desde la linea de comandos usando >fsx /ManualLoad Esto provee un dialogo para todas las dll's o xml ejecutadas que son cargadas para que puedas interrumpir la que está jodiendo la marrana si hay algún problema. Sin embargo, mucha gente no conoce la forma de ejecutar FSX desde la línea de comandos, que es la manera más segura de desinstalar todos los añadidos. Si has efectuado cualquier truqui de modificación de archivos, necesitarás desinstalar o reparar la RTM (dichosa RTM). Entonces instala SP1 Luego comienza a instalar tus añadidos de uno en uno. Nota: Desinstalando RTM (¿copia ya instalada?) borra TODO el contenido de: C:\Documents and Settings\All Users\Application Data\Microsoft\FSX C:\Documents and Settings\TUUSUARIO\Application Data\Microsoft\FSX Esto ocurre en TODAS las subcarpetas y archivos de esa rama Si no haces copia de seguridad y la guardas, perderás archivos de configuración, vuelos, logbook y recompensas. Dos archivos para considerar salvarlos: Logbook.bin y GrantedRewards.bin FSInsider.com tendrá un artículo vivo (¿reciente?) que discute la desisntalación de escenarios en más profundiad, por favor, tomate el tiempo para leerlo. --------- Mantendré añadiendo cosas y trucos según salgan, pero para ser honesto, creo que SP1 se balancea como es (¿?, es una mierda pinchada en un palo?) Bueno, traducción terminada , aunque algunos conceptos técnicos no he sabido darles la traducción que merecen por desconocer exactamente lo que significan, así que si alguien puede meter mano ahí... Mi inglés tampoco es que vaya muy allá, así que no os fieis mucho de lo que digo Un saludo!! :P Edited July 22, 2007 by TzT Quote Link to comment Share on other sites More sharing options...
Santi_ Posted July 21, 2007 Report Share Posted July 21, 2007 Joer traducido y todo , genial. No lo voy a usar de momento pero gracias . Tzt Quote Link to comment Share on other sites More sharing options...
zaar69 Posted July 21, 2007 Author Report Share Posted July 21, 2007 Muchisimas gracias!! Esta tarde hare algunos cambios y veremos que tal va.... Un Saludo. Quote Link to comment Share on other sites More sharing options...
kgusto Posted July 21, 2007 Report Share Posted July 21, 2007 Muchisimas gracias Tzt, buen trabajo Quote Link to comment Share on other sites More sharing options...
TzT Posted July 22, 2007 Report Share Posted July 22, 2007 Bueno, post traducido al completo Mira que es enorme el post. Si llego a saberlo antes lo iba a traducir quien yo me se Un saludo!! :P Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.