Embedded display working with one GPU, not with another

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
Post Reply
PhreakShow
Posts: 4
Joined: 06 Feb 2023, 17:59

Embedded display working with one GPU, not with another

Post by PhreakShow » 06 Feb 2023, 18:37

Hey guys,

I am not sure if I am in the right spot here, but my question is about advanced display stuff and I really don't know where lse to look.

I build displays for embedded systems, and add an HDMI or DVI to the display. The display timings I usually know, so I create an EDID in my eeprom or use toastyx's best tool ever, cru.

The display in question has 2880x960 and 60Hz, the other parameters like front and back porch are also know. Let's say it got a total of 3151 by 981 resolution, at 60Hz this equals 185.46786 Mhz. EDID requires me to round that value, for example 185.47 MHz. Now the pixel clock is slightly higher, what does that mean in my case?
If I connect that display to my 1070 card, I get an image. If I connect it to an Intel or even a 2070, the screen stays black.

Why is that the case? Due to my rounding? How do I determine which parameters to use in that case?

Also, is there a signal generator available for HDMI, like a handheld device where I can just add the timing parameters and then easily create a test image, like a checker board? Then I'd adjust the values on the fly, try and get a stable image, and then put those values in the EDID. Or wouldn't this solve my problem with the display being driven on one video card and not on another?

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Embedded display working with one GPU, not with another

Post by Chief Blur Buster » 06 Feb 2023, 22:22

What's your budget? HDMI signal generators are fairly expensive.

BTW, I saw a few HDMI display signal generators at DisplayWeek 2022 which were rather neat, including AstroDesign Inc. (in HDMI Forum booth). There's a convention called DisplayWeek 2023 in Los Angeles (May 23-25) if you want to explore and look at multiple vendors that may help.
PhreakShow wrote:
06 Feb 2023, 18:37
Why is that the case? Due to my rounding? How do I determine which parameters to use in that case?
It may or may not be the rounding, but another behavior. It's hard to trace this.

One way to experiment is to use a third party utility such as ToastyX to use quicker software-based EDID overrides and create them via Windows while using 2 monitors. Keep experimenting with new ToastyX software-based EDID overrides (installed into Windows Registry) until all 3 GPUs work.

1. Connect two monitors to the same computer (a normal display and your custom display). Use the safe monitor (e.g. 1080p bog standard) as your primary monitor.
2. Use a Windows software-based EDID override creator such as ToastyX Custom Resolution Utility at www.monitortests.com
(Don't forget to donate some money to his Patreon, if you support his tool).
3. Tweak things around a little bit (you can test hundreds of custom resolutions per hour) until all your 3 GPUs work. Use your primary monitor to keep manipulating the EDID override to test a variation.

These forced EDID overrides don't require the custom EDIDs in your monitor yet; this is only for testings' sake;

Test
- Non-VESA formulas (custom resolutions)
- Slightly higher pixel clock
- Slightly lower pixel clock
- A few extra / a few fewer porch pixels (both horizontals and verticals).

Until a picture reappears on your non-working GPU. Once that happens, try the other GPUs too.

Once you find the EDID that works (EDID, E-DID, CEA-861, DisplayID, or whatever format you use), install it into the monitor. Remember you can get more fine Pixel Clock control with DisplayID, but I recognize not all devices support the newer plug-and-play formats. However, it is an option if you need to do workarounds.

Also, check that it's not a bandwidth aberration (e.g. older GPUs that doesn't support HDMI 1.4 or whatnot), so stick only to recent GPUs, when you're using computers manually as budget signal generators.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

PhreakShow
Posts: 4
Joined: 06 Feb 2023, 17:59

Re: Embedded display working with one GPU, not with another

Post by PhreakShow » 07 Feb 2023, 06:32

Thanks for your answer. I didn't think about a budget yet, because I had to idea what to look for exactly. If it's 500, and the generators are one order of magitutde move expensive, then 500 is pretty useless. Let's say the budget is around 1000, if we can get in the vicinity of what is needed in my case.

What I found during research was this:
https://www.a-neuvideo.com/shop/product ... cts_id=124

But I am not sure if that device allows me to adjust the timings easily, without having to edit the EDID and writing it back every time I change one parameter.

You gave me a manual for adjusting the timings with a safe monitor. That's what I am doing right now, and it pretty exhausting because it takes forever.

What happens from a driver's point of view if the pixel clock is slightly too high or too low? Does the driver adjust other parameters, like the refresh rate, to match an exact clock?

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Embedded display working with one GPU, not with another

Post by Chief Blur Buster » 25 Feb 2023, 13:55

PhreakShow wrote:
07 Feb 2023, 06:32
You gave me a manual for adjusting the timings with a safe monitor. That's what I am doing right now, and it pretty exhausting because it takes forever.
Can you tell me suggestions on how it could be made much easier? I've been talking to ToastyX to add an API to ToastyX CRU, which might allow external utilities to speed up tweaking.
PhreakShow wrote:
07 Feb 2023, 06:32
What happens from a driver's point of view if the pixel clock is slightly too high or too low? Does the driver adjust other parameters, like the refresh rate, to match an exact clock?
Pixel clock is simply (Horizontal Total) times (Vertical Total) times (Decimal Refresh Rate), in the number of pixels/sec transmitted over video cable. So slightly high at same HT and VT = slightly higher refresh rate.

As long as Pixel clock is within the bandwidth window of your GPU and your video cable, and your display supports the odd refresh rate, there is no side effect at all. It's just a mathematical compromise of integer-roundoffs and the precision of the clock chips inside the GPU, on how fine granularity you can adjust the Hz or Pixel Clock (which are linked).

You can adjust bit depth 6bit vs 8bit vs 10bit. So if your HDMI cable is 77 gigabits/sec, and your GPU is capable of that bandwidth, then allow about 10-20% overhead for other things (e.g. HDMI audio, HDMI packetization, etc) and your bitbucket becomes 60-65 gigabits/sec. As long as your HT x VT x PixelClock x BitDepth = within your budget, and the display shows a picture, you're fine.

Embedded displays can be unusually picky, so tracking down how it's picky can be a gigantic challenge -- it might be sync polarity, it might be a Horizontal Total, it might be a Vertical Total. Especially if the embedded panel has no plug-and-play EDID ("Hello computer, I'm a display. I can support these exact timing numbers at these exact refresh rates... Please only use these modes."), which can automatically cause a Radeon and GeForce GPU to output slightly different timings numbers, that cause one to work but not the other to work. Displays should not be that unforgiving, usually. Try viewing the numbers that a GPU uses, and then copying every single number to the target GPU -- so that the exact mode is used.

Even 1080p on one computer is slightly different than 1080p on a different computer when talking to a display that is not transmitting any Plug-and-Play EDID. In the lack of EDIDs, the display can never instruct the computer what modes it supports, and you're forced to "blindly output timings" to such a display. In that situation, go to the working GPU and get the exact signal timings from that computer -- all the way to sync polarity values, and every exact number in Custom Resolution (You can view the exact numbers of the current resolution via various utilities)

You gotta UNDERSTAND every single number in a Custom Resolution Utility and why each number exists.

Do you understand each number? Every single number? Do you know why a "Horizontal Front Porch" exists, traced all the way back to a 1920s Baird/Farnsworth analog television? Be honest.

If not, please read these threads to stop unnecesary blind tweaking, and more surgical time-saving tweaking:
Custom Resolution Utility Glossary.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

PhreakShow
Posts: 4
Joined: 06 Feb 2023, 17:59

Re: Embedded display working with one GPU, not with another

Post by PhreakShow » 27 Feb 2023, 18:37

What annoys me most is the reboot. I don't know if that is possible, but a tool that could change the values on the fly, as soon as I confirm them, would be nice, but I think that's a driver limitation? Then a lot of possible values could be checked with the click of a button.

What determines the budget of my video card? One of my test computers has a 1060, which is capable of 7680x4320@60Hz, DP 1.43, HDMI 2.0b according to the nvidia page, thats almost 2GHz of pixel clock, ignoring the overhead of our invisible sync pixels, and also ignoring compression (if any).
The display I am trying to get to work has a datasheet which states all the needed values. I have total, active, front/back porch, sync and polarity, horizontal and vertical, and a given pixel clock that is equal to the value I get if I calculate it manually. Colour depth is also known, simple 8bit per colour. It is an embedded display, but I got the values from the manufacturer.

The EDID I wrote myself, using all those values and one of the freely available EDID generators on the web. The EDID is written to an I2C EEPROM, and after that I confirmed the transmitted values using cru. Checksums I also confirmed, using the wiki article on EDID.

Here the weird stuff begins. The video cards seem to react differently to the EDID. The 1060 seems pretty robust in this matter, as soon as I connect the display the monitor banks for a second, while the driver enables the second output, but no image appears on the second display.
Another computer with an intel gpu doesn't even blank/recognize the attached display, although the support for such a resolution is there. As soon as I change a few values, like porch or sync, even increase them and thus increase the pixel clock, it gets recognised by the driver, but still no image is shown.

I did read about the different values that make up an image, I think the h front porch exists to give the beam time to make its way from the end of the line to the beginning of the next one? The periods between the active pixels and the sync pulse are called porches.
I wouldn't brag about knowing every value and its origin, no. But, given I have the datasheet and the needed values, does it matter that much? Or so I thought...
What else is there. Refresh rate? Pretty self explanatory, the number of times the image is refreshed per second. Active is of course the visible area, and the polarity determines the direction of the edge, either falling or rising.

There's a similar display from a different manufacturer that works perfectly. It has the same active resolution, but the porches are roughly four times the size of the not working display. Of course, the working one has a higher pixel clock, but even that works on all my test computers, including the 1060 and the intel, so I am definitely withing my timing budget in that matter, right?
For both displays I have the datasheet, for both displays I worked the same way in creating the EDID EEPROM. That's why I don't get why the display with the higher bandwidth requirement works, and the other does not.

I also tried using the higher values of the working display with the failing one, but of course, that didn't work out.

You describes the mechanism of an EDID in your answer. The EDID has integers for all values, but as you said, this doesn't always work out due to rounding. How does the video card determine, what to do in this case? Which values does it prioritize over others, like lowering the refresh rate from 60.000 to 59.995 Hz to match the clock? Or vice versa?
Given the bandwidth budget is noth exhausted, why does my intel not even recognize the display until I start increasing the front/back porch by 1 or 2, also increasing the pixel clock along with it?

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Embedded display working with one GPU, not with another

Post by Chief Blur Buster » 02 Mar 2023, 03:44

PhreakShow wrote:
27 Feb 2023, 18:37
What annoys me most is the reboot. I don't know if that is possible, but a tool that could change the values on the fly, as soon as I confirm them, would be nice, but I think that's a driver limitation? Then a lot of possible values could be checked with the click of a button.
Are you aware of ToastyX restart64.exe?
It restarts the GPU driver (1 second screen blackout).
Faster than rebooting the computer.
PhreakShow wrote:
27 Feb 2023, 18:37
You describes the mechanism of an EDID in your answer. The EDID has integers for all values, but as you said, this doesn't always work out due to rounding. How does the video card determine, what to do in this case? Which values does it prioritize over others, like lowering the refresh rate from 60.000 to 59.995 Hz to match the clock? Or vice versa?
Given the bandwidth budget is noth exhausted, why does my intel not even recognize the display until I start increasing the front/back porch by 1 or 2, also increasing the pixel clock along with it?
Sounds like you know what you are doing for the most part. Assuming you structured your EDIDs correctly, or are blind-forcing the custom mode (EDID-less, creating EDIDs only via Windows registry).

But some tips, which you may have overlooked.

I assume you also tried intentionally decreasing your pixel clock to compensate for the increase in porch (etc). Some GPUs like Intel needs enough VBI time to function properly, because some PC-based GPUs have bugs that prevent them from working if blanking is too small; this may be happening to your Intel GPU -- I have heard of this happen. The workaround is to use bigger VBI (porches) like your fix. And you can most definitely fix the refresh rate by lowering your pixel clock to compensate. Your manufacturer of embedded screen may not have tested on the flawed Intel GPU that failed to work with too-small blanking intervals (due to housekeeping that needed to execute between refresh cycles).

Since pixel clock is simply number of pixels per second, and if you're running into rounding errors with larger porches, simply readjust both the HORIZONTAL TOTAL and VERTICAL TOTAL a few times until you're able to get back to an exact 60.000 if that's important to you for any reason (even 60.000 might be 59.998 on one GPU, 60.002 on another GPU, 60.001 on yet another). Try to keep your vertical total an even number for simplicity sake, and your horizontal total divisible by 8. Focussing on atomic-clock quality 60.000000000000000 is a losing battle. But if it's just EDID tidiness, you can easily get the EDID to math 60.00000000000000 (read onwards) if your EDID hygiene is a bigger priority than atomic-clock accuracy of refresh cycle timings. Many monitors ship with weird 60Hz refresh rates including 59.979 or 60.013, but you can get it to math better if you want.

Embedded screens are usually low resolutions, and you are only doing 60.000 Hz, and even a 15-year-old GPU can out-bandwidth many embedded screens. So just waste a higher Pixel Clock to get better compatibility. You MUST have a good reason to stay with tiny porches -- do you? If not, then definitely don't do tiny porches. (I still tell screen manufacturers to support them, both tiny porches and big porches, in flexible tolerance abilities. But not all GPUs work reliably with tiny porches, sadly).

Now let's imagine you're a 1024x768 embedded display, you could simply fudge (1024 + horizontal blanking) and (768 + vertical blanking) to have numbers that creates tidier clocks. Keep the numbers even and creates cleaner multiplication. You might find that 1080x800 (HTxVT) produces easier refresh rate and pixel clock math for you, and easier to hit 60.000. So the side effect of increasing vertical total by 1 may necessitate increasing by 2 instead, while simultaneously increasing/decreasing HT to create a tidier number that creates better timings math. Whenever unsure, always err on bigger totals / sync / porches. More time for the display to sync between pixel rows, or between refresh cycles.

Image

Ask yourself: Why do you need to keep your blankings too tiny? That is usually an expensive compatibility nightmare especially if there's too few clock cycles between last pixel of previous refresh cycle, and first pixel of new refresh cycle -- not enough time for some housekeeping tasks that occur on certain GPUs while the GPU is waiting between refresh cycles. Just waste extra GPU bandwidth on bigger porches that are much more compatible, and make sure the maths rounds-off correctly.

Glossary
VBI = Vertical Blanking Interval = (Vertical Front Porch + Vertical Sync + Vertical Back Porch)
HBI = Horizontal Blanking Interval = (Horizontal Front Porch + Horizontal Sync + Horizontal Back Porch)
VT = Vertical Total = (All verticals added together, including visible pixels)
HT = Horizontal Total = (All horizontals added together, including visible pixels)
Dot Clock = Pixel Clock = (Horizontal Total) x (Vertical Total) x (Refresh Rate)
Scan Rate = Horizontal Refresh Rate = (Vertical Total) x (Refresh Rate)

If you didn't know this by now, you didn't read the links I posted in the earlier message...

Conceptually, signal timing are metaphorically like virtual resolution with pixels beyond the screen bezels. They had an overscan and sync purpose on CRT tubes, now they're simply dummy (comma-separatoresque) pixels in digital. Analog and digital has a 1:1 timing conversion, which is why passive bufferless 1080p adaptor exist to convert 1080p VGA to 1080p DVI/HDMI (at least in the unpacketized HDMI 1.0 era) and vice versa without needing any buffer in the analog-digital adaptor. We've been using the same signal topology at this signal layer for almost 100 years, from the 1920s Baird/Farnsworth TVs, all the way to 2020s DisplayPort, it's just conceptually a serialization of 2D image into 1D (wire or broadcast) and it timings-survived the switch from analog to digital, unmodified!

For example, a 960x960 screen might work better with 1000x1000 including blanking intervals, which makes it 1 million pixels per refresh cycle, and at 60Hz (multiply the virtual resolution by 60.000) creating a very tidy 60 million pixel per second pixel clock (60.000MHz) that has no rounding errors. And if those porches are not big enough, fudge things around (e.g. 1080x1080, 1000x1080, 1200x1200, etc) until the pixel clock only has many zeros after a few significant digits. No rounding errors in your EDID to worry about! So don't do 979x993 porches with a 960x960 specialty LCD, you gotta know how to math all of this out properly to save time. Remember (Horizontal Total) x (Vertical Total) x (Refresh Rate) = (Pixel Clock)? If you didn't know that, now you do, and you can stop testing and simply pick up a pocket calculator first to create some proposed numbers.

Imagine it as a virtual resolution bigger than the screen, and pixels are transmitted over the cable one pixel at a time, left-to-right, top-to-bottom (high speed videos of scanout: www.blurbusters.com/scanout ...) ... it's a raster serialization of 2D image over 1D cable. Pixel Clock is always exactly every single pixel of this "virtual resolution" times refresh rate. So now you want a tidier Horizontal Total and a tidier Vertical Total (both even numbers that mutliply better) and multiplies more easily by 60.000 to create an exact pixel clock concurrently with an exact refresh rate with no rounding error. So you have an incentive to intentionally deviate away from a flawed EDID recommendation by a manufacturer and create your better more compatible EDID. But you MUST understand every single number and WHY rounding errors happen.

Remember clock chips and clock crystals are not perfect, so 60.05Hz may be 59.95Hz in realtime (atomic clock). If exact Hz is important to you, you must measure it externally (oscilloscope, logic analyzer, etc). Otherwise, don't worry too much about off-by-a-smidge situations in a nitpicking fashion. Remember, GPU clocks can slew against CPU clocks (temperature), so your timing drift may cause different refresh rates at different temperatures (Example: www.testufo.com/refreshrate#digits=8 after 30 minutes of unattended execution).

This number is very sensitive to slew between CPU clock tickrate and GPU clock tickrate, so even power management (SpeedStep) can affect these numbers. Actual 3rd party measurements also actually measure refresh rate drift too from mere things like temperature and such. This happens to all video sources (whether a DVD player or cable box), and you may find that even two adjacent models of television settop video player boxes of them play a few milliseconds faster/slower over a period of an hour, even with perfect zero framedrops.

Different GPU vendors do things slightly differently, annoyingly, but most displays tolerate major variations. That's why a cheap $99 LCD such as a HP 60Hz or DELL 60Hz monitor works just fine at 48Hz-72Hz in literally 0.001Hz increments, and some of the units tolerates 3-pixel VBIs (1 pixel front porch, 1 pixel sync, 1 pixel back porch) if the GPU (e.g. NVIDIA) can handle functioning properly at such tight porches. These cheap generic LCDs are still very porch-forgiving (tiny/big HTs and VTs).

And if it wasn't the too-tiny porch issue, why isn't your embedded display more forgiving? Why isn't your display more compatible with bigger porches as a workaround? Etc. I would blame the manufacturer of the embedded display for designing such poor firmware. I wouldn't necessarily use the EDID recommendation that the embedded vendor gives -- I would use an EDID that works on worst-case Intel/NVIDIA/AMD product.

It seems like your embedded display is astoundingly unusually picky, beyond any reasonable means. I would walk away from it, while lighting it in a dumpster fire.

My humble opinion is that tolerance margins should be +/- 5% at absolute minimum, not +/- 0.1% like your display seems to be.

Unless it's a new technology (e.g. micro OLED or such) that is understandably going through bleeding edge design, LCD panels are very forgiving (sometimes unusually forgiving, such as generic 60Hz LCD overclocked to 180Hz+ when it didn't have bad firmware code standing in the way)

You may want to buy a different embedded display that is more forgiving. My verdict: If it's just a random mere ordinary 60Hz LCD from Alibaba, put the embedded display containing sloppy intern-programmed firmware into a dumpster, and light the dumpster on fire as a financial waste of time if you are a business, or a waste of life if you are personal (and can afford the cost of a couple or three more other random Alibaba embedded displays).

Get a few other more candidates. One day of wasted billable hours of work at a business pays for a small fleet of better embedded LCDs to test, one by one.

Now if it's a specialty prototype like a MicroLED or Micro OLED, okay -- fair enough -- but if it's just a mere ordinary 60Hz LCD -- why are you still wasting time with one containing sloppy timing-intolerant firmware? Alibaba offers over 100 models of embedded LCDs, many of which has undocumented >5% forgivingness in its tweakability. Of course, it might be the GPU's fault (porches too tiny for the GPU to properly function -- this can annoyingly happen). If your business product need GPU-agnostic ability (e.g. embedded display that works with any GPU) then you have a financial interest to intentionally deviate away from the embedded display manufacturers' recommended EDID.

Or if you're building a custom product (e.g. you are a hardware manufacturer and you specced out for an exact size embedded screen and it is too costly to retool your factory), then you've got a costly pick-poison choice faced in front of you.

Or if it's a DIY box with a custom 3D printed holder for an embedded screen, just get a similar size and print an plastic adaptor to fit your slightly-different-sized (off by a few millimeters or whatever) embedded LCD.

Understandably my advice may not apply here -- Ask yourself; If the screen goes black with smaller AND bigger porches, then ask yourself: How stuck are you with THIS embedded screen if you're unable to deviate away from the manufacturer EDID recommendation?

And if you're hell bent on trying to get the manufacturer EDID recommendation to work, they obviously didn't QA test enough to cover all those edge cases (like certain GPUs that goes blank if the VBIs are too tiny because they didn't have enough time to execute housekeeping between refresh cycles). Remember, if horizontal scanrate is 100 Kilohertz, and you have a 50-line VBI (porches + sync), that means you have 50/100,000th of a second between refresh cycles. Your act of increasing by 1 may have given enough CPU cycles to an Intel GPU to finish housekeeping between refresh cycles. That may have been what happened. A flaw in a specific GPU that the other GPU did not have. Etc.

So that's why bigger porches is almost always better for compatibility. Yesteryear big porches was to give enough time for the momentum of electron beam to move back to the top edge. But today, big porches are still needed as guard delays for maximal compatibility, to give some signal sources enough time to do between-refresh-cycle processing tasks. I don't know what the minimums are for all GPUs ever manufactured in humankind, but my NVIDIA GPU can do ultra-tiny 3-pixel VBIs just fine (1 pixel each!). But I've seen certain Intel and AMD GPUs utterly and completely fail at that before. Now, if you're failing at much bigger porches too (damned if you do, damned if you dont), then that embedded screen feels like an unnecessary time&money drain.

I can tell you far beyond my two hands the many times I've told manufacturers to fix their flawed EDID recommendation to improve compatibility or fix problems like frameskipping (e.g. One example is the famous 240Hz frameskipping debacle at viewtopic.php?t=3598 ...) and this is big-budget 240Hz, not tiny-budget 60Hz embedded LCDs that might just be repurposed 15-year-old tablet/smartphone screens from an old fab factory they want to keep running, with old inflexible duct tape firmware making them barely work on only one computer that they tested. Barf.

Hopefully this helps you surgically select the right tree in the forest -- it's all often a learning experience. Exit the side door away from time waste, and just surigcally hone into perfection faster. If the embedded screen won't let you (fails at both significant increase/decrease, e.g. -2 and +2 increases in porches etc), get a different one (with more forgiving tolerances). I have no patience for intolerant LCDs anymore, given >99%+ of what I use are very forgiving nowadays.

SUMMARY
  1. Numero Uno Most Important Rule: manufacturer EDID = only guideline Manufacturer EDID recommendation on many specialty screens is sometimes just a "suggestion". Deviate away from it to suit your priorities (e.g. better compatibility) especially if you have ability to reprogram the EDID
  2. Second Rule: Bigger is better for bug-free compatibility. Unless your embedded screen is absurdly high refresh rate (like 1000Hz) or absurdly high resolution (like 8K), please just merely waste your GPU pixel clock on more porch/sync padding for Intel+NVIDIA+AMD compatibility. Thank me later.
  3. Third Rule: Pick up a pocket calculator more often. If EDID "60.000" tidiness is important, keep inflating the totals on paper (away from testing) until you create a mathematically neater virtual resolution (Horizontal Total) x (Vertical Total) that when multiplied by exact refresh rate, creates a very tidy Pixel Clock number that has few significant digits. (Or vice versa, a tidy total number of pixels per refresh cycle, that is easy to multiply by 60). Minimizes your rounding errors for EDID editors that gives you limited number of significant digits. Once you got your HT x VT x Hz = PixelClock correct, split your HT and VT any whichever way you want (porches and sync), it doesn't matter as long as your HT and VT is unchanged, and it works on all your GPUs.
  4. Embedded screen selection flexibility If this embedded screen won't let you do it on nearly first try, get a different embedded screen that lets you succed (1)(2)(3) on the FIRST TRY.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

PhreakShow
Posts: 4
Joined: 06 Feb 2023, 17:59

Re: Embedded display working with one GPU, not with another

Post by PhreakShow » 17 Jan 2024, 17:50

I did never thank you for that behemoth of a detailed answer: Thanks.

The topic has come up again, and I am again working on it. Thanks also for your pm, and sorry for ghosting you.
I had a lot of stuff going on.

Post Reply