Jump to content

AngieAndretti

Registered User
  • Posts

    50
  • Joined

  • Last visited

About AngieAndretti

  • Birthday 06/11/1985

Profile Information

  • Gender
    Female
  • Location
    NYS, USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

AngieAndretti's Achievements

T|I Semi Advanced

T|I Semi Advanced (3/7)

19

Reputation

  1. I have two nVidia 1070 MXM cards, one with G-SYNC and the other without but otherwise identical - but because of G-SYNC their device ID's don't match. G-SYNC=1BE1 and NO G-SYNC=1BA1. I'd like to force-flash one of the cards to match the other for the purposes of running SLI without software-level hacks. I've read about others force-flashing 1070's using other SPI Programmers like the SkyPro II but I do not own one. I do own a Raspberry Pi 3 Model B, which I've successfully used as an SPI programmer in the recent past. Problem I'm having is that my 1070 uses a Macronix MX25U8033E chip for VBIOS and this isn't explicitly listed as something supported by the flashrom software. I do know that the 8033U is a 1.8v chip from reading its datasheet, so I cannot use the 3.3v output from the Pi to power the chip as I did with my other flashing experiments, so I connected an external DC power supply to send 1.8v to my chip clip and passed the other pins through to the Pi as normal. Unfortunately flashrom sees no chip connected so I cannot read nor write. Any ideas? Yes I can purchase a SkyPro II if absolutely needed but I'd really love to get this working with the Pi!
  2. Some Successes! Thanks a lot for making me look into this deeper, Qon. I had originally tried something similar without success: I set a negative offset within the OS, at first using Intel XTU, as I find it preferable to the Sager control center software and as I said it would work UNTIL I'd reboot the system. Upon reboot, BIOS would immediately powercycle the system and change that negative to a positive value along with changing the CPU PL1 and PL2 limits to very low values, about 30w limit. When the system then got into Windows, I could see in XTU that we were now running a positive overvolt and this was confirmed with HwInfo64 - the CPU was truly getting more voltage rather than less. I did try that same process once with Sager's control center before my first post and I initially got the same result, but your post made me check deeper... After reading your suggestion that it actually might be possible to get this working, I tried setting a negative offset again using the Sager software but I noticed something strange: When I clicked "Save" after selecting the undervolt, the Save button remained highlighted as it seems to do when it's trying to indicate that there are unsaved settings being displayed. So I clicked it a second time and only then did it become gray, likely indicating the settings had in fact saved. Upon reboot the machine still powercycled that one first time and BIOS did still display a positive offset value but the PL1 and PL2 values remained untouched this time and now when booting to Windows, we actually hold the correct undervolt despite BIOS displaying the positive value. So the takeaway for others is this: If you're having this issue with CPU undervolt not sticking or getting inverted to a positive value when setting it in Sager's Control Center, try clicking Save a second time after selecting your preferred settings, or until the Save button returns to being gray. Now regarding the "Lazy VSYNC" issue I mentioned in which framerate often dropped notably below the chosen refresh rate without the CPU or GPU indicating that they were being taxed significantly at that moment. I don't know for sure if this is a Pascal-specific issue but I can say the same games that exhibited this issue played flawlessly with the same nVidia driver versions installed on my Maxwell-based laptop. I did a lot of tinkering with nVidia Profile Inspector (v.2.1.3.4) and I found the following settings to be a near-perfect fix, at least in the games I was having issues with: Variable Refresh Rate: 0x00000000 VSYNCVRRCONTROL_DISABLE Framerate Limiter 2 Control: 0x00000002 PS_FRAMERATE_LIMITER_2_CONTROL_AVOID_NOOP (or) 0x00000011 PS_FRAMERATE_LIMITER_2_CONTROL_DEFAULT_FOR_GM10X (depending on game) Frame Rate Monitor: 0x00000010 PS_FRAMERATE_LIMITER_GPS_CTRL_TARGET_RENDER_TIME_SHIFT Frame Rate Monitor Control: 0x0080F364 PS_FRAMERATE_MONITOR_CTRL_VSYNC_OPTIMAL_SETTING Note these settings are to be used in conjunction with VSYNC ON, as the issues I was having were specific to VSYNC being ON. These settings also work great with Power Management Mode set to "Optimal Performance" (Profile Inspector) = "Optimal Power" (nVidia Control Panel) which allows the GPU to only clock up as high as it needs to in real-time. They in fact work far better than simply setting Power Management Mode to "Prefer Optimal Performance" which tends to keep the GPU clock rate high at all times, which I find very undesirable on a laptop. I also found the answer to my #4 quirk, in which only the 120hz internal display setting could be used as a template for creating custom refresh rates in between 60 and 120hz. It was because the native 60hz configuration, for some reason, had about 1,000 extra "total pixels" programmed onto the back end of the vertical refresh in the display timings, leading to the 60hz pixel clock being the same as the 120hz pixel clock. Don't ask me why they did that, but if you try to increase the refresh rate using the 60hz template, you end up with a pixel clock that's too high and out-of-range... unless you reduce the "total pixels" vertical setting in the display timings to a lesser amount.
  3. I've recently purchased Sager's new P9872-S laptop with Intel i7-6700K unlocked CPU and a single nVidia 1070 XMX GPU. Let me say that overall I absolutely LOVE this new machine, but I've discovered some strange hardware/BIOS type quirks that I'd like to discuss here. Note: I don't see a version displayed in my BIOS, but HWINFO lists a BIOS date of 10/19/16. The CPU is unlocked and supports overclocking. The stock BIOS also has a section for CPU overclocking. My CPU is quite happy running a moderate 4.5GHz OC across all cores with a 70mV undervolt (offset mode.) Yes it'll do the same clock at stock voltage but I've found that many Skylake CPU's do not need such high voltage as Intel has programmed them for - and my temps run much lower with the undervolt. So I set the undervolt with Intel XTU (I've also tried doing the same with Sager's own utility) and it runs beautifully until I reboot the system. At POST, BIOS then seems to reject the undervolt, forces a power-cycle, and sets CPU PL1 and PL2 power specs to very low "safe" levels. It also changes the negative voltage offset to a positive 70mV, indicating that it's trying to "error correct" the negative value. BIOS itself specifies a valid range of -500 to +500mV for the voltage offset here, and I can change it directly within the BIOS (and then it DOES actually stick through future reboots) but the BIOS does not allow me to enter a negative value here! Instead of -500 to +500, the actual values it allows for entry are 0 to +1000! And no, +500 does not actually equal zero, tried that and it really is +500. Also of note, I can change any multipliers in XTU or Sager's utility without the BIOS objecting but *any change* to the voltage offset gets rejected at reboot - even +1mV. Even applying +1mV and then immediately applying 0mV in either utility gets rejected on the next reboot so it's as if some checksums or something are not calculated the same way by XTU as they are by BIOS, causing a rejection of *any* voltage offset modification made by a utility rather than BIOS itself. Initially I set all my CPU core multipliers to 45x and all was good. Soon I noticed that any time I put the computer to sleep or hibernate, it would limit core speed to a maximum 42x after recovering, despite still reporting 45x as the CPU maximum. I tinkered with it for a while and eventually tried different values. Now I have ONE CORE multi set to 46x and TWO, THREE, and FOUR CORE multi set to the original 45x. That shouldn’t make a lick of difference versus 45x across the board but it does! 46, 45, 45, 45 sticks properly through sleep and hibernate; Weird right? I’m fine with the current settings as an effective workaround but I feel it’s still worth noting here. The VSYNC seems "lazy." I know this may be a driver or settings issue, rather than true hardware quirk, but it really bothers me - and the same behavior exists with nVidia drivers 368.xx to 373.06. Take Dirt Rally for example; I want it to run with VSYNC ON at 1080p, 90Hz. If I turn VSYNC OFF, my average framerate is about 200Hz, and never falls below about 110Hz, but with VSYNC ON it keeps dipping momentarily below 90Hz and skips frames! In a fast-motion racing game this is very distracting! I've observed this same behavior with the internal LCD and with my AOC 144Hz gaming monitor connected via DisplayPort. With VSYNC OFF, even with framerate limiter set at or just above my refresh rate, the game looks terrible so this is not an acceptable workaround either. Yes, the reported refresh rate is on target without VSYNC but there's terrible tearing and stutter. I've never experienced this kind of VSYNC dysfunction before; any thoughts? I have the 1920x1080 120Hz LCD screen. I wanted to set a couple custom refresh rates in nVidia Control Panel for racing games that really stress the system at 120Hz but I still want more than 60Hz. If the LCD starts out set at 60Hz and I test a custom resolution of 1920x1080 at, say, 90Hz, the screen goes kaput until it reverts back to 60Hz. However, if the screen starts out set at 120Hz I can then create any custom refresh rate in between 60 and 120Hz that I want. I wouldn't bother trying to fix this one as there's a perfectly functional workaround - it's just weird to me that starting frequency matters. Any thoughts on these quirks are welcome, and I’d be happy to try/test any good suggestion or curiosity you might have. Especially getting a negative CPU voltage offset to stick permanently, as well as any thoughts on the VSYNC laziness would be greatly appreciated. Thanks everyone!
  4. I own a Gigabyte G1 Gaming Edition of nVidia's massive new 980ti GPU. It's a great card as-is but I do love to tinker and I'm aware that it uses the same core (GM200 I believe) as the new Titan X GPU, the only difference aside from the 6gb GDDR5 RAM versus the Titan's 12GB is that some of the CUDA cores are disabled on the 980ti, giving it 2,816 active cores instead of the full 3,072 on the Titan X. I'm curious if it would be possible to flash a 980ti so it thinks it's a Titan X and would therefore use that additional block of previously disabled cores. I remember it was once very easy to do this with, say, the old ATI Radeon cards - one could buy a certain relatively cheap card, flash it to something better that used the same core, and even bolt on a better cooling fan, overclock, and that's all it would take to build a way stronger rig for a bargain price. Those were the days, right! I'm sure there are safeguards in place now to make this more difficult because companies like nVidia don't like to lose money, and that difference in amount of video RAM might require a "hybrid" modded VBIOS, but do you think it could be done? What obstacles would have to be overcome? Where might I start in researching this further?
  5. I hear you, but it's not the driver that came with THIS system nor is it the version presented by Dell for this system (the secondary components presented for install don't match up either) and I doubt very seriously that its dysfunction is due to anything I've done. No modified driver has ever successfully installed on this system, and any failed attempt has always been followed up with a clean install of 350.12 from the nVidia website. I was under the impression that you believed you were able to modify the vBIOS in a way that would allow any driver to allow overclock - and more so than +135MHz. Now when this thing failed the first time around, system restore to an earlier point also failed (I've found it terribly unreliable on Win8.1 despite being rock-solid on 7) so I had to restore back to the first full system backup I created just after installing all necessary software on the system. That was before any attempts to modify anything, so at this point in the system's lifespan, it's had the original pre-installed Dell driver replaced with 350.12 and that's it; nothing else. Now if I run DDU and install the driver you suggest and it still fails a second time, can we please move on to the vBIOS?
  6. No, nothing is messed up from earlier attempts to modify anything. I went from a fully stock 350.12 to the 347.90 provided and it made a terrible mess. Nothing inf-modded has ever installed on this system - it always fails to install if attempted, and this is not the fault of the existing driver. Furthermore I'm not looking to go through the messy recovery process from installing the 347.90 driver a second time. I'm looking for a modified vBIOS that allows use of the regular old driver from the nVidia website which installs happily without error, as does the slightly earlier, but later than 347.90, version provided on the Dell support downloads site for this machine.
  7. So I downloaded that driver, 347.90 via the link provided, ran it normally, and it actually bolloxed the system. Specifically it appeared to install (clean install) but produced no nVidia icon in the system tray. Upon immediate reboot, Windows appeared to "think" it was working normally behind the scenes, but the display output was all black and the system was unusable. As for the newer nvflash, I just tested it and got the same result as before. Initially I had ran it with an actual game running in the background, but holding the dGPU open with GPU-Z yields the same result: I'd sure appreciate a system BIOS including a vBIOS modded with your "new method!"
  8. I attempted to use the modified nvdmi.inf file, pasted into driver version 347.88 - and it does act like it can install (doesn't say the hardware is incompatible) but the final summary screen indicates it fails to install the graphics driver. This is the same result I got when patching nvdmi.inf from driver version 350.12 into 347.88 before I made contact with you. If you know what's going wrong, let's see if we can tackle it, but let it be known that I'm ultimately looking for a larger overclock capacity than +135MHz. The last thing I want is to sound ungrateful but we're already talking about a chip that achieves a boost speed of 1197MHz out of the box, so +135 is about an 11% increase. I was able to achieve a 70% increase on my 650m (M14xR2) and it was 100% stable. Now I guess it's possible I won the silicon lottery on that machine but that's the kind of testing I want to do on this new unit. If I were modding the vBIOS, which I'm pretty sure will require extracting and pasting back into the main system BIOS (which I'd also love to have unlocked for that matter) I'd set the OC limit to, say, +800MHz and see how high I can go before encountering artifacts or disturbing temperatures. svl7 created something wonderful which I used on my M14x a couple years back. It was a combination of his fully unlocked system BIOS and an integrated vBIOS that was labelled "for testing" which allowed very high OC speeds to be set - and that single download absolutely transformed the capabilities of that little machine, putting it nearly on-par with my AMD 7970m-powered m17xR4! Now I'm not looking to go into this with expectations for similar performance, but I've owned four of these Alienware laptops now and I really get the feeling that this one is not pushing anywhere near its true performance limits. The highest dGPU temperature I've been able to evoke was 64C, and I've never noticed anything higher than 62C in an actual game. Also the fans do not seem to spin at maximum speed, ever. I've observed what they do during Dell's system BIOS update, which locks them to max for the duration of the update, and nothing I can throw at this machine makes them spin nearly that fast! Whether that's a limitation in the BIOS itself, intended to make the machine quieter, or due to it not getting hot enough to need the full cooling power, I can't say at this time... but everything I'm observing tells me the true potential of this machine has yet to be unlocked! I do have a lot of well-rounded knowledge when it comes to the PC platform and I've worked in the industry for fifteen years, but with the exception of changing a POST-screen image once a few years back, BIOS modding is sadly not in my wheelhouse. Now if someone out there is willing to attempt creation of an unlocked BIOS/vBIOS mod for the 960m-based Alienware 13, I'd be willing to pay for that person's time, as well as to provide a test platform. And on that note, if we could roll something out for testing before June 7th, it would be easier for me to recover from the possibility of a bricked machine because I would still be eligible to exchange the machine outright if it failed, which I've found in my own experience to be a lot less painful than dealing with a warranty call for a bad motherboard. Regardless, thank you Prema for your time in this so far!! Have a great weekend everyone!
  9. Yes I'm aware of that, like my previous M11x and M14x. What surprises me is that the vbios alone can not be extracted at least for viewing using either of these tools. Tell me if I'm wrong, but I guess you're suggesting one would open the main system BIOS rom file, as provided by Dell, extract the vbios from that, do their modding, and re-integrate it for flashing when finished?
  10. Prema, Thank you for your reply! Attached is the nvdmi.inf from driver version 347.88. +135MHz sounds like an improvement, for sure, but I was hoping to see just how far you can go on this system - as I've read that Maxwell has extreme overclocking potential, limited by little else than your ability to dissipate heat. For that matter, I do remember being able to successfully overclock my 650m by over 450MHz with a modded system BIOS. On that note, I've also uploaded two screenshots - one attempting to save the current vBIOS with GPU-Z, and another attempting the same with svl7's mnvflash utility. Both fail, as GPU-Z reports "BIOS reading is not supported on this device" and mnvflash throws a more specific error. There does appear to be a key in the registry, under HKLM\System\CurrentControlSet\Control\Class ... nVidia card's key, that appears to be the entire contents of the vBIOS - and I could upload that but even if you could use it in the form of a .reg file to do some modding we'd be left with the question of how to re-flash the product, as mnvflash appears to fail regardless of whether there's an nVidia driver installed or not. My ultimate goal here is obviously a modified vBIOS that allows for a ton of overclocking headroom to play with, and I'd appreciate anything you can do to help me work toward that goal - and for the possibility to create and test something to post and share with the community, but in the meantime I understand and respect that you're busy so a modded inf file would be appreciated as well! ... whenever you have the time; Thank you!! My full hardware ID is as follows: PCI\VEN_10DE&DEV_139B&REV_A2 nvdmi.zip
  11. OK, thank you, you did answer my question in the literal sense but what I'm really after here is a link, download, or a procedure. I mean I'm sure it CAN be done, but as yet I've been unable to come up with anything that works. nVidia has disabled overclocking at the vBIOS and/or driver level, and since this thread is about modded vBIOS for the 970m & 980m, I was hoping to inspire a mod for the 960m as well. I can provide my stock vBIOS if necessary.
  12. Is it possible to unlock overclocking in the 960m's vBIOS, as per Alienware 13?
  13. I just recently received my newest Alienware purchase - the new 13" model with an nVidia GeForce GTX 960m (a Maxwell chip.) I'm aware of the recent debacle in which nVidia disabled all mobile overclocking in their drivers, I believe versions 345.09 and up. It's also been said that they've disabled it in their new vBIOSes as well. However I was able to uncover a link in which users are confirming that version 347.88 enabled overclocking even on cards that are intended to be clock-blocked in vBIOS: NVIDIA 347.88 Game Ready Driver - 17/03 (re-enables overclocking!) | NotebookReview There's even a user who reports having inf-modded that driver to allow installation with the new 960m, and claims to have unlocked overclocking capability. However, as yet I've been unsuccessful in modding that same driver to install on my system. I've copied the main ListDevices.txt file and all the .inf files in the Display.Driver folder over from version 350.12 which naturally supports the 960m but the result reports "required files are missing" and will not install. Could someone with more experience than I when it comes to inf-modding a driver give me some pointers? Any other ideas or solutions for unlocking the likely massive OC potential of the 960m? vBIOS mod perhaps? I've seen a mod for the 970m along with a modified nvflash EXE. I can provide my current vBIOS if anyone is willing to look into it!! Thank you!!
  14. Further Examination reveals that it is display dithering going on on the Intel side, and tweaking the color palette in AMD's CCC can compensate for the color banding that makes the display look interlaced - so the question becomes: How can I tell the AMD 7970m to dither the display colors like the Intel chip does? There are many AMD-specific registry settings that affect how the display looks but I've yet to find a solution there... any thoughts?
  15. Follow-Up: Does it have to do with display dithering or some other technique that Intel is using to fake more colors than my LCD can actually display? My 1600x900 LVDS display is native 6 bits per primary color per pixel. I found an article that stresses how 6bpp can only result in a true representation of 262,144 actual colors - so Intel must be doing something with their GPU to make the display appear to represent more colors than it actually can, right? And when we connect the AMD GPU directly we are not getting this effect. Is there something I can change, perhaps a registry setting or Window display color profile, that would compensate similarly to whatever Intel is up to? Does this make sense?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.