TM4C129XNCZAD TFT LCD

The answer here is "maybe". Unfortunately there are a lot of variables involved so I would need a fair bit more information before I could give you a straight "yes" or "no".

1. What refresh rate do you need to drive the display at (50Hz, 60Hz, 75Hz)?

2. What color depth do you need the frame buffer to be (1bpp, 4bpp, 8bpp, 16bpp)?

3. What kind of redraw rates will your application require (simple HMI with a few buttons or full screen animation)?

The LCD controller can, technically, handle displays up to 2Kx2K pixels but the bottleneck is pretty much always accessing the SDRAM across the EPI interface. If you have an application which needs to drive a large display but doesn't need to draw too many graphics too quickly (for example, a typical HMI with a collection of buttons and a few indicators over a static background), that will possibly work whereas, if you are trying to display fast animation, you may find that you don't have enough memory bandwidth to both write the pixels you need and refresh the display.

In our testing, we've not yet tried anything about 800x480. Using an 8bpp frame buffer and assuming 60Hz refresh rate, your display is going to need somewhere around 40MBps just to refresh or about 40% of the bandwidth available on the EPI when running at 50MHz. If you need a 16bpp frame buffer, I would guess that it becomes impractical because 80% of your bandwidth would be used up just for refresh leaving the CPU very little bandwidth to use to draw pixels into the frame buffer.

PS: This all assumes that your display uses a raster (VSYNC/HSYNC/DATA/CLOCK) interface and doesn't have an onboard frame buffer and controller, of course. If it does have an onboard controller and buffer, then none of this applies and it is more likely that you could use it successfully assuming, of course, that you can interface it to the TM4C129 part.